PB-2389: onboard renovate

[KeeTraxx]

Onboard renovate. The first PRs will come on the weekend after it has been merged.

Test link

[cypress]

web-mapviewer    Run #6609

Run Properties:   Passed #6609  •  9e29b173d9: PB-2389: onboard renovate

Project	web-mapviewer
Branch Review	feat_PB-2389_renovate-onboarding
Run status	Passed #6609
Run duration	05m 03s
Commit	9e29b173d9: PB-2389: onboard renovate
Committer	Khôi Tran
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	0
Pending	19
Skipped	0
Passing	222
View all changes introduced in this branch ↗︎

[schtibe]

Two thoughts:

• Maybe we could do a little cleanup beforehand. For instance, we have "hammerjs" in the workspace but judging from a quick grep it isn't even being used anywhere
• I wonder if we should stick to minor updates or even tighten it to patch (adding ~ instead of ^). I don't have a clear opinion on this, maybe it's also a question to be answered case-by-case. Like if a minor update breaks the codebase, then we fix it to patch?

Also there are a few packages in the workspace that are fixed to a specific version. In some cases it's documented why, in other's it's not apparent if it's by mistake.

[hansmannj]

Clean-up as mentioned by @schtibe might make sense, if it does not consume too much time.
Otherwise, since this repo is legacy, we could move ahead even if it is not something we'd do with a more actively maintained repo.
We could also stay with minor versions and only tighten to patch if needed IMHO.

[romankaravia]

I just noticed that we already have pinned dependency versions in pnpm-workspace.yaml, such as this one:

    # prettier-plugin-jsdoc 1.6+ creates many "Max call stack size exceeded" errors when used in tandem with prettier-plugin-tailwindcss
    # waiting for a fix, see https://github.com/hosseinmd/prettier-plugin-jsdoc/pull/255
    prettier-plugin-jsdoc: 1.5.0

=> I think it would make sense to have a single place, where we pin versions and add comments why this is the case. Meaning we would have to decide between renovate.json and pnpm-workspace.yaml.

My (maybe somewhat radical?) proposal would be:

• We pin all versions in pnpm-workspace.yaml
• Despite the "pinning", we regularly update dependencies via renovate, with the exception of some dependencies that are excluded via renovate.json

Pros

• Single place to document "really pinned" dependencies in renovate.json
• Easier to understand, which dependency versions we are using (can look at pnpm-workspace.yaml, no need to look at pnpm-lock.yaml for direct dependencies)

Cons

• If we publish libraries with pinned dependency versions from our workspace, library users might be more "stuck" with the pinned versions. (but not a big deal IMHO, because we would also update them on a regular basis, and it could even provide more stability)

[schtibe]

My (maybe somewhat radical?) proposal would be:

* We pin all versions in `pnpm-workspace.yaml`

* Despite the "pinning", we regularly update dependencies via renovate, with the exception of some dependencies that are excluded via `renovate.json`

Maybe not the worst idea since renovate will try to update things regardless of the version definition in pnpm-workspace.yml, correct?

[hansmannj]

If I understand that correctly, we are not really "pinning" versions here, so renovate will still suggest to update "pinned versions", if need be, right?
And the versions, that are really in use, are the ones in pnpm-workspace.yaml, right?

Might be worth a short comment/documentations somewhere, so that no one takes the pinning for a "version granted" thing?

Otherwise, I like the idea! 👍