chore: upgrade d3-color and d3-scale-chromatic

[icco]

Done to match other packages

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
nivo	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 3, 2024 10:08pm

[OleksandrRakovets]

@icco Can you please update pnpm-lock.yaml as well, so tests could show whether updated versions would work?

Looking forward to this shipped as minor to resolve the vulnerabilities.

[icco]

@OleksandrRakovets I haven't used pnpm before, but ran pnpm install and pushed the diff

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 67c3056:

Sandbox	Source
nivo	Configuration

[jclarkcisco]

Looks good. Can we get this in and make everyone's scans happy again, please? :)

[RicardoAALL]

@plouc any chance of getting this merged?

[plouc]

The version bumps look OK, however the lock file has 25,722 additions, 34,184 deletions which doesn't seem right.

[sebastianarena]

+1 to this! please merge!

[srubio131]

As a temporary solution and in order not to have to wait for dependency updates, you can use overrides to force a particular version of d3-color to be used in your project.

package.json
... "resolutions": { "d3-color": "3.0.0" } ...

Note: Yarn has "resolutions" and pnpm "overrides" too, and works in a similar way

[icco]

The version bumps look OK, however the lock file has 25,722 additions, 34,184 deletions which doesn't seem right.

@plouc I just ran the default pnpm install command. What's the correct way to generate this lock file?

[BruceHubbard]

I pulled down the branch to see why it had that many changes in the lock file and 98% of the changes are whitespace. It looks like the lockfile that is in master uses 4 spaces to indent and this PR instead uses 2 spaces to indent. When I look at the diff using git diff -w it cuts down on the changes quite a bit but there is still stuff like this that shows up:

It's moving the react specifier a LOT of times from 18.2.0 to >= 16.14.0 < 19.0.0:

       react:
-                specifier: 18.2.0
+        specifier: '>= 16.14.0 < 19.0.0'
         version: 18.2.0

It's changing the spacing of a LOT integrity fields:

   /@alloc/[email protected]:
-        resolution:
-            {
-                integrity: sha512-UrcABB+4bUrFABwbluTIBErXwvbsU/V7TZWfmbgJfbkwiBuziS9gxdODUyuiecfdGQ85jglMW6juS3+z5TsKLw==,
-            }
+    resolution: {integrity: sha512-UrcABB+4bUrFABwbluTIBErXwvbsU/V7TZWfmbgJfbkwiBuziS9gxdODUyuiecfdGQ85jglMW6juS3+z5TsKLw==}

I verified this behavior by pulling down the PR branch, replacing the lock file with the one from master, making sure I'm using [email protected] (as specified in the package.json), and then rerunning make init. I ended up with the same lockfile as this PR. Is there a different version of pnpm that doesn't change the whitespace as much? Or some kind of setting for it?

[plouc]

@BruceHubbard, thank you for checking, I tried myself and got the same result, not sure why though, but those changes should be fine then, and the specifier field is aligned with what's defined in the packages. So LGTM, and thank you for the contribution @icco!