search

remix-run / remix

Build Better Websites. Create modern, resilient user experiences with web fundamentals.
https://remix.run
MIT License
30.02k stars 2.53k forks source link

🗺️ Repo Tooling #7923

Open ryanflorence opened 1 year ago

ryanflorence commented 1 year ago
lensbart commented 1 year ago

If yarn → pnpm is inspired by speed or disk size, it might be worthwhile to consider upgrading from the currently used Yarn 1 to the latest version 4, which might be an easier upgrade path for similar benefits. It offers the choice of pnpm/Plug‘n’Play/node_modules strategies.

See also this discussion which can be closed afterwards. Yarn “berry” imposes stricter rules on dependencies (e.g. you can’t import a node_module unless it’s listed in your package.json, even though it might be available on disk due to another package having it installed). Not sure if pnpm is similarly strict (no experience), but it would be nice to get an additional safeguard here to avoid regressions like those listed in the linked discussion.

Thanks

leothorp commented 12 months ago

@lensbart RE: pnpm and restrictions on importing unlisted dependencies- pnpm offers the same capability.

pnpm's default behavior is "semistrict"- dependencies in node_modules can import each other without declaring the dependency, but modules outside of node_modules cannot (source). It also offers the https://pnpm.io/npmrc#hoist option, which makes that fully strict when set to false- i.e., all modules everywhere must explicitly declare everything to have access to it.

My impression is that pnpm has more developer mindshare than yarn 4- I'd see that as a point in its favor in this case (not familiar with yarn 4 though, might have other advantages)