chore: use pnpm catalog to manage dependencies

[KazariEX]

[pkg-pr-new[bot]]

Open in Stackblitz

vue-component-meta

npm i https://pkg.pr.new/vuejs/language-tools/vue-component-meta@5174

vue-component-type-helpers

npm i https://pkg.pr.new/vuejs/language-tools/vue-component-type-helpers@5174

@vue/language-core

npm i https://pkg.pr.new/vuejs/language-tools/@vue/language-core@5174

@vue/language-plugin-pug

npm i https://pkg.pr.new/vuejs/language-tools/@vue/language-plugin-pug@5174

@vue/language-server

npm i https://pkg.pr.new/vuejs/language-tools/@vue/language-server@5174

@vue/language-service

npm i https://pkg.pr.new/vuejs/language-tools/@vue/language-service@5174

vue-tsc

npm i https://pkg.pr.new/vuejs/language-tools/vue-tsc@5174

@vue/typescript-plugin

npm i https://pkg.pr.new/vuejs/language-tools/@vue/typescript-plugin@5174

commit: 82dd59f

[johnsoncodehk]

After more thought, I think that switching to catalog is not without cost. While this reduces duplication of configuration, it also introduces complexity, and package.json is no longer compatible with npm (we sometimes need to publish a single package using npm publish when the lerna publishing process is interrupted due to network reasons).

At present, catalog is still not a good enough solution. We can see if there are better methods or tools in the future.

[ghiscoding]

(we sometimes need to publish a single package using npm publish when the lerna publishing process is interrupted due to network reasons).

@johnsoncodehk @KazariEX Perhaps you didn't know but Lerna-Lite can now recover from such failures, it was added 2 years ago in this Lerna-Lite PR publish: recover from network failure. You simply have to recall the lerna publish command and let it resume from where it previously stopped, which allows you to recover from a possible failure. So you don't have to go with npm to publish, but it's a bit more tricky do deal with that in a CI workflow.

So with that in consideration, you have 2 ways of dealing with this and I recently encountered these problems (yesterday actually) and I'm also using Lerna-Lite with catalog: in a large project of mine. I had such issue because I use OTP (one-time-password) and it expired before every packages had time to be published (only 80% ended up being published), so I tried these 2 ways to fix my issue:

1. create a separate workflow to retry lerna publish only
   • which is what I've done here publish-npm-publish-retry.yml
   • this worked, I was able to recover using this approach
2. or modify your CI workflow with bash to automatically detect publish error and ask for a new OTP then retry lerna publish
   • which is what I also changed in my publish worflow
   • it should work, just didn't have a chance to fully test this approach yet (I only ran it once and only partially, so not fully tested but it should work)

I tried the number 1 first and it totally worked, I was able to resume my publish. As for the number 2, I didn't fully try it yet since it didn't fail since then but I'm pretty sure it will work... but in the end, in my case the publish problem I had with OTP expiration was caused by Husky running ESLint when lerna publish starts which delayed my publish and caused my OTP to expire and my publish to fail. I can help implementing any of these 2 options above for CI or if you run lerna publish locally then just re-run a publish when these errors happen and that will fix it.

So you can totally use this pnpm catalog: if you have proper CI workflow code to deal with possible lerna publish errors. There's no reasons to stick with the old approach if catalog can improve your maintenance (it helps in my project to remove duplicates and have Renovate update only 1 location).

Cheers