More constructive, I find it harder to read/write, one more thing to learn (as if newbies don’t already have trouble figuring prod/dev), requires additional tooling. All that for nice categorisation doesn’t feel like a proper tradeoff, & deviates from the initial reason pnpm catalogs was introduced - ThreadSky

bluwy.me • 34 days ago

More constructive, I find it harder to read/write, one more thing to learn (as if newbies don’t already have trouble figuring prod/dev), requires additional tooling. All that for nice categorisation doesn’t feel like a proper tradeoff, & deviates from the initial reason pnpm catalogs was introduced

Comments

antfu.me•34 days ago

> deviates from the initial reason pnpm catalogs was introduced

Hammer is not designed for open walnut, but could be a nice tool to do that when you don’t have a better tool around.

I don’t think there is a problem to use a tool within its designed functionality.

bluwy.me•33 days ago

For sure, I meant the problems and tradeoff that’s going on here doesn’t justify that

antfu.me•33 days ago

I see. But are you rejecting the idea of catalogs at all, or do you see a better solution for this? (for monorepo versions management and categorization)

bluwy.me•33 days ago

I think it's an interesting idea for monorepo version management, but I feel the cases where they're useful are kinda niche. If you're bumping dependencies to latest all the time, then there's almost no worries for out-of-sync deps. I wish pnpm had documented the motive and usecases better though.

baxuz.bsky.social•33 days ago

It's a great solution for dev deps, and production deps alike.

I have a monorepo with ~10 test apps and 6 packages. Each one of them a number of shared deps including vite, TS, prettier, eslint.

I also want to keep the framework deps in sync.

baxuz.bsky.social•33 days ago

For those cases, I feel like this is a much better solution compared to either dep hoisting or using tools like syncpack.

antfu.me•33 days ago

It’s not only about out-of-sync, bumping versions in a single file instead of a dozen of package.json is also better for reviewing and diffing.

If one already uses catalogs in their monorepo, leveraging it to also categorize deps does not introduce a lot trade offs

baxuz.bsky.social•33 days ago

It's less error prone as well. I currently use `npm-check-updates -ui -ws --root` as it's the most reliable way to update deps, but it takes a long-ass time to go over dozens of packages in larger repos.

After that I run `syncpack fix-mismatches` for the obligatory errors.

bluwy.me•33 days ago

I usually use pnpm outdated or renovate for bumping deps and they give an overview of changed dependencies which felt enough for me. I’d sacrifice some review time so my package.json stays readable.

antfu.me•34 days ago

> as if newbies don’t already have trouble figuring prod/dev

Isn’t that the problem I am trying to mention? Prod/dev doesn’t make sense for apps that’s why it’s hard to understand.

> tradeoff

What’s the tradeoff? If it’s about tooling, that’s something we should help improve.

bluwy.me•34 days ago

It does make sense for apps depending on how it’s deployed, eg npm i —prod for node apps.

The tradeoff is as I mentioned, harder to read/write etc. Resulting in more compounding tooling needed to resolve them and complexity for new users.

bluwy.me•34 days ago

From my experience, there’s been many times reading package.json to be met with a ton of “catalog:” making me have to look around figuring out the version. I don’t want to install an extension just to easily read versions.

Comments

Posting Rules

Reply