preserveSymlinks doesn't work properly from root packageSee original GitHub issue
Consider a library
lib with the following file structure:
root - common - node_modules - resolve - buffer - mylib - node_modules - buffer -> ../../common/node_modules/buffer - src - index.js
In other words, a dependency exists from the root library to
buffer which is symlinked into a separate folder (similar to how pnpm works).
In this case,
resolve doesn’t seem to be mapping the symlinked paths to real paths properly.
- Create the above example with mkdir/ln -s
- cd into root/mylib/src, run node.exe
resolveand observe that
resolve('buffer/')returns the symlinked path (
root/mylib/node_modules/buffer) instead of the real path (
- Created 4 years ago
- Comments:11 (4 by maintainers)
Top GitHub Comments
in the “preserve symlinks” case - which node used to do by default - resolve is correct.
Hmmm… If the aim is to mimic the return value of the
require.resolve() API from NodeJS, then I agree it should be changed. The fix is pretty easy; call
fs.realpathSync() on the return value.
I suspect the reasons this hasn’t been reported before include that resolve’s
preserveSymlinks: falsebehavior is relatively newly added, and also symlinking is done pretty rarely historically.
Symlinks are used heavily in installations done by PNPM and also Rush, though. By now most tools support that, and rely on the
resolve package somehow in their solution. Thus perhaps the explanation is that most callers don’t care whether the result is normalized or not. For example, here and here is code that works fine when traversing symlinks, because the next step is to load the file, and it doesn’t really matter whether that path is normalized or not.
If we fix this “bug”, it might be a good idea to release it as SemVer MINOR (or MAJOR?), since it could theoretically break tools that might have relied on the current behavior somehow.