-
-
Save GiladShoham/b8d29c2ffb39bf99ee1b5ccc92b3eb90 to your computer and use it in GitHub Desktop.
const fs = require('fs'); | |
try { | |
require('my-package'); | |
console.log('succuss require my-package'); | |
} catch (err) { | |
console.log('failed require my-package'); | |
} | |
fs.symlinkSync('pathToMyPackageInAnotherFolder', './node_modules/my-package', 'dir'); | |
try { | |
require('my-package'); | |
console.log('succuss require my-package'); | |
} catch (err) { | |
console.log('failed require my-package'); | |
} |
Looks like this issue only happens when the symlinked package has no index.js
in the root of the package and uses the main field in package.json
to point to a custom entry js file.
I have created a repo that demonstrates the issue: https://github.com/zkochan/require-symlink-issue
Sure (I was a little surprised my initial test worked) though Node generally doesn't make guarantees about what require
does in these scenarios so it working or not is happenstance and I doubt this would be fixed as a bug.
I recall a lot of issues around this behavior (and --preseve-symlinks) and if I recall correctly it stalled on someone doing the work. I think those discussions predate the loader/modules team and I'm not even sure if cjs is in scope for that team. If I recall correctly you participated in those discussions too - right?
I would bring up your use case (presumably bit's or pnpm's?) in nodejs/node - I suspect it's significantly easier to do/workaround than before and I suspect that if pnpm puts its weight behind this and changing it doesn't cause ecosystem breakage it has a good chance of being done.
(You can of course work around it by symlinking to an entry in the same subpath and using that as a "jump off" point to require the other path - but that may probably break without notice in Node.js at any time)
It is not related to symlinks. I updated the example to use real files.
And I have filed an issue in node.js: nodejs/node#44663
this worked