The problem is that a lot of package are developed on the assumption that the dependency tree is flat, esp. dev dependencies. I've tried using pnpm on multiple projects, and all failed because babel, eslint or some other dev dependency could not resolve a dependency which it expects to exist as a result of dependency tree flattening (esp. eslint plugins).
While this is not an issue with pnpm, and pnpm should not promote possibly harmful practices, the lack of this feature makes pnpm less useful of a tool.
When was it that you tried pnpm on different projects? There indeed were issues with pnpm and pluggable frameworks but we have fixed most of them. _If you'll have specific problems, feel free to create issues for them._
If there are packages that depend on the flat dependency tree, they are incorrectly written. If a package uses another package, it has to have it in some dependencies or peerDependencies property.
What I plan to do to solve this issue, is some tooling to analyze the dependency tree for any possible usages of unreferenced packages. That will allow us to find issues really quick. Also tools like publish-please can be extended to check for missing packages before publish.
P.S. Supporting such an option would add a lot more complexity to pnpm. And running pnpm with this option would make it a lot slower, probably even slower than yarn or even npm. It might still use less disk space, but that's not such a big deal. I just recommend using npm/yarn in such cases
@gajus [email protected] has now an option to create a flat node_modules.
Most helpful comment
@gajus [email protected] has now an option to create a flat
node_modules.