CI: disable pinning dependencies

[aloisklink]

📑 Summary

Disabling pinning dependencies using renovate.

We've got a pnpm.lock file that pins dependencies for us.

Renovate should automatically update all the x.MINOR.PATCH versions automatically too, e.g. #3714

Ideally, we'd have a renovate lockFileMaintenance too, but that's not yet supported for PNPM.

See Renovate Docs | Should you Pin your JavaScript Dependencies?

📋 Tasks

Make sure you

• 📖 have read the contribution guidelines
• 💻 have added unit/e2e tests (if appropriate)
  • Not applicable.
• 🔖 targeted develop branch

[sidharthv96]

@aloisklink sync?
@knsv Any issues with not pinning?

[aloisklink]

@aloisklink sync?

Synced :)

It's a bit of a pain, since renovate keeps on bumping the package.json automatically, which causes merge conflicts.

I might just need to re-sync everything and merge this PR my self once everything has been approved!

Any issues with not pinning?

Renovate has some docs on this: https://docs.renovatebot.com/dependency-pinning/#what-a-lock-file-doesnt-do-for-you

Most of these don't apply to us, since renovate should automatically bump all of our dependencies from ^1.2.3 to ^1.2.4, and the `pnpm.lock.

Generally, my gut feeling is only to pin dependencies if we know their next x.x.MINOR patch causes a bug (e.g. like what happened with documentation), or if the package is not very maintained and we don't want an auto-update without verifying the code first.

[markrian]

I was about to open a similar PR, but for DOMPurify in packages/mermaid specifically. Would it make sense to unpin that here as well?

Currently, consumers of mermaid end up with a specific version of dimpurify pulled in, and to deduplicate that need to use something like resolutions or overrides.

I'm referring to this line, which is the only pinned dependency there.

[aloisklink]

I was about to open a similar PR, but for DOMPurify in packages/mermaid specifically. Would it make sense to unpin that here as well?

My gut feeling is that we should do it in a separate PR.

This PR is just to revert the dependencies that were previously unpinned, since that's less controversial.

dompurify was already pinned as a dependency before we switched to renovate, and has been pinned ever since it was first added, see b468065

Personally, I'm happy to unpin dompurify as well, but there might be a reason why it was pinned (maybe security issues?), so I'd rather have it in a separate PR so it doesn't block the rest of the changes.

---

I've git rebase-d onto the develop branch (if we keep everything in a single git revert commit, it will make it much easier to view the git history).

@sidharthv96, I've dropped your fix Dompurify change, since I feel like it's probably better to stick it in another PR (as discussed above in my comment).

Also, you deleted line

mermaid/packages/mermaid-mindmap/package.json

Line 51 in 653682a

"mermaid": "workspace:*",

in the merge commit, but I've kept it, since I'm not sure what it does.

Btw, if people are happy with this PR but can't merge due to merge conflicts, let me know and I'll be happy to fix them and merge this PR myself.

[sidharthv96]

You're right, we should keep the rest of the stuff separate.

[sidharthv96]

Knut mentioned there were issues with rendering pie charts with some d3 versions.
Can you please test if pie charts render properly?

[aloisklink]

The latest version of d3 is 7.6.1, so using ^7.6.1 changes nothing, at least until d3 releases an update (even then, somebody/renovate would need to update the pnpm-lock.yaml file for us to use the new version), see https://github.com/d3/d3/releases

Important

As far as I'm aware, overrides only affect our local environment, it won't affect people doing npm install mermaid. They'll have two versions of d3:

• the ^7.0.0 version specified in dependencies (unchanged in this PR):

  mermaid/packages/mermaid/package.json

  Line 56 in 653682a

  "d3": "^7.0.0",

  
  Maybe pie charts won't work with older versions of ^7.0.0? I'll test this and make another PR if this is the case. Works with 7.0.4, so it should be fine to leave as ^7.0.0.
• the ^5.14 version specified by mermaid's dagre-d3 dependency (also unchanged in this PR)
  This needs to be fixed by replacing dagre-d3 with another package. dagre-d3-es seems good, but we may need to fork it/make a PR since it doesn't export all the functions we need, see Update packages to fix vulnerabilities #3712 (review) and Update packages to fix vulnerabilities #3712 (comment))

---

It seems to work fine when I run the following commands:

git clean -fxd # make sure nothing is cached
pnpm install
pnpm run dev

Then going to http://localhost:9000/pie.html shows:

[sidharthv96]

Yes, we should move on from abandoned packages.

• jison
• dagre
• dagre-d3

3 of our core deps, all 3 deprecated. :(

[aloisklink]

Pie charts still work with "d3": "7.0.4", so I think it's fine to leave "d3": "^7.0.0" in mermaid's dependencies.

Again, that wouldn't change anything with the older version of d3 found in node_modules/dagre-d3/node_modules/d3, which has "d3": "^5.14, which will happen when running npm/yarn/pnpm install mermaid (their package manager will ignore mermaid's "resolutions": {"d3": "^7.6.1"} field).