4 ms·

Hot take: pnpm is the best dx, of all p/l dep toolchains, for devs who are operating regularly in many projects. Get me the deps this project needs, get them f

Hot take: pnpm is the best dx, of all p/l dep toolchains, for devs who are operating regularly in many projects. Get me the deps this project needs, get them fast, then them correctly, all with minimum hoops. Cargo and deno toolchains are pretty good too. Opam, gleam, mvn/gradle, stack, npm/yarn, nix even, pip/poetry/whatever-python-malarkey, go, composer, …what other stuff have i used in the past 12 months… c/c++ doesn’t really have a first class std other than global sys deps (so ill refer back to nix or os package managers). Getting the stuff you need where you need it is always doable. Some toolchains are just above and beyond, batteries included, ready for productivity.

theogravity 2y ago
pnpm is the best for monorepos. I've tried yarn workspaces and npm's idea of it and nothing comes close to the DX of pnpm
- paularmstrong 2y ago
  What actually, as an end user, about pnpm is better than Yarn? I've never found an advantage with pnpm in all the times I've tried it. They seem very 1:1 to me, but Yarn edges it out thanks to it having a plugin system and its ability to automatically pull `@types/` packages when needed.
  - wruza 2y ago
    automatically pull `@types/` packages when needed Wait, what? Since when?
    - paularmstrong 2y ago
      It's a plugin that's included by default in Yarn 4: https://yarnpkg.com/api/plugin-typescript https://yarnpkg.com/api/plugin-typescript In Yarn 2/3, it needs to be added manually.
krashidov 2y ago
Have you used bun? It's also great. Super fast
mdaniel 2y ago
I swear I'm not trolling: what do you not like about modern golang's dep management (e.g. go.mod and go.sum)? I agree that the old days of "there are 15 dep managers, good luck" was high chaos. And those who do cutesy shit like using "replace" in their go.mod[1] is sus but as far as dx $(go get) that caches by default in $XDG_CACHE_DIR and uses $GOPROXY I think is great 1: https://github.com/opentofu/opentofu/blob/v1.9.0/go.mod#L271 https://github.com/opentofu/opentofu/blob/v1.9.0/go.mod#L271
- geethree 2y ago
  To be fair your specific example is due to… well forking terraform due to hashicorp licensing changes.
  - mdaniel 2y ago
    hcl is still MPLv2 https://github.com/hashicorp/hcl/blob/v2.23.0/LICENSE https://github.com/hashicorp/hcl/blob/v2.23.0/LICENSE and my complaint is that the .go file has one import path but the compiler is going to secretly use a fork, versus updating the import path like a sane person. The only way anyone would know to check for why the complied code behaves differently is to know that trickery was possible And that's not even getting into this horseshit: https://github.com/opentofu/hcl/blob/v2.20.1/go.mod#L1 https://github.com/opentofu/hcl/blob/v2.20.1/go.mod#L1 which apparently allows one to declare a repos _import_ path to be different from the url used to fetch it I have a similar complaint about how in the world anyone would know how "gopkg.in/yaml.v3" secretly resolved to view-source:https://gopkg.in/yaml.v3?go-get=1 https://gopkg.in/yaml.v3?go-get=1

theogravity 2y ago

pnpm is the best for monorepos. I've tried yarn workspaces and npm's idea of it and nothing comes close to the DX of pnpm

paularmstrong 2y ago
What actually, as an end user, about pnpm is better than Yarn? I've never found an advantage with pnpm in all the times I've tried it. They seem very 1:1 to me, but Yarn edges it out thanks to it having a plugin system and its ability to automatically pull `@types/` packages when needed.
- wruza 2y ago
  automatically pull `@types/` packages when needed Wait, what? Since when?
  - paularmstrong 2y ago
    It's a plugin that's included by default in Yarn 4: https://yarnpkg.com/api/plugin-typescript https://yarnpkg.com/api/plugin-typescript In Yarn 2/3, it needs to be added manually.

krashidov 2y ago

Have you used bun? It's also great. Super fast

mdaniel 2y ago

I swear I'm not trolling: what do you not like about modern golang's dep management (e.g. go.mod and go.sum)? I agree that the old days of "there are 15 dep managers, good luck" was high chaos. And those who do cutesy shit like using "replace" in their go.mod[1] is sus but as far as dx $(go get) that caches by default in $XDG_CACHE_DIR and uses $GOPROXY I think is great 1: https://github.com/opentofu/opentofu/blob/v1.9.0/go.mod#L271 https://github.com/opentofu/opentofu/blob/v1.9.0/go.mod#L271

geethree 2y ago
To be fair your specific example is due to… well forking terraform due to hashicorp licensing changes.
- mdaniel 2y ago
  hcl is still MPLv2 https://github.com/hashicorp/hcl/blob/v2.23.0/LICENSE https://github.com/hashicorp/hcl/blob/v2.23.0/LICENSE and my complaint is that the .go file has one import path but the compiler is going to secretly use a fork, versus updating the import path like a sane person. The only way anyone would know to check for why the complied code behaves differently is to know that trickery was possible And that's not even getting into this horseshit: https://github.com/opentofu/hcl/blob/v2.20.1/go.mod#L1 https://github.com/opentofu/hcl/blob/v2.20.1/go.mod#L1 which apparently allows one to declare a repos _import_ path to be different from the url used to fetch it I have a similar complaint about how in the world anyone would know how "gopkg.in/yaml.v3" secretly resolved to view-source:https://gopkg.in/yaml.v3?go-get=1 https://gopkg.in/yaml.v3?go-get=1