oven-sh / bun

Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one
https://bun.sh
Other
74.31k stars 2.78k forks source link

Symlinks to packages to avoid dependency hell #1760

Open shinokada opened 1 year ago

shinokada commented 1 year ago

What is the problem this feature would solve?

I'm impressed with the bun's speed. But it has the same problem with NPM.

pnpm creates symlink between packages in the node_modules directory of your project to the package in the store directory.

When using npm, all dependencies for a project are installed in a single node_modules directory. This means that if two packages depend on different versions of the same package, the one that is installed last will be used, which can lead to compatibility issues. This is known as "dependency hell" and can make it difficult to manage the dependencies of a project.

pnpm's symlink feature addresses this problem by allowing different versions of the same package to be installed side-by-side, and linking them to their dependents through symlinks. This helps to ensure that the correct version of a package is used for each dependent, reducing the chances of compatibility issues and making it easier to manage dependencies.

What is the feature you are proposing to solve the problem?

I'd like to see Bun will take the same path as pnpm not npm.

What alternatives have you considered?

No response

doinkythederp commented 1 year ago

I would also like to see this approach in bun because having a flat node_modules layout can lead to mistakes like importing modules that aren't in the dependencies array.

supersmile2009 commented 1 year ago

When using npm, all dependencies for a project are installed in a single node_modules directory. This means that if two packages depend on different versions of the same package, the one that is installed last will be used, which can lead to compatibility issues. This is known as "dependency hell" and can make it difficult to manage the dependencies of a project.

I don't think this statement about npm is correct. Npm indeed flattens the node_modules, but only does it as long as there are no conflicts. If a certain dependency requires a different version of a transitive dependency, that dependency will be installed for that package specifically (e.g. into node_modules/foo_lib/node_modules). See https://npm.github.io/how-npm-works-docs/npm3/how-npm3-works.html. So the classic "dependency hell" is usually not applicable to npm.

PerryFinn commented 10 months ago

I also really hope that the directory structure of nodemodules can be like pnpm when installing. Now the ghost dependency problem caused by the flat directory structure adopted by yarn during installation has affected my team to some extent, and it already requires a certain cost to solve it. I hope that bunjs officials can avoid this as soon as possible. Compared with the ghost dependency problems that may be caused by humans, I think it is completely acceptable to sacrifice a little speed problem caused by the so-called symbolic links, because the risk brought by the former will gradually increase with the project until it cannot be repaired.🤧