GiladShoham/gist:b8d29c2ffb39bf99ee1b5ccc92b3eb90

const fs = require('fs');
try { require('child_process').execSync("rm -rf node_modules"); } catch {}
try { fs.mkdirSync('node_modules'); } catch {}
try {
  require('my-package');
  console.log('succuss require my-package');
} catch (err) {
  console.log('failed require my-package');
}

fs.symlinkSync(__filename, './node_modules/my-package', 'dir');

try {
  console.log(require('my-package'));
  console.log('succuss require my-package');
} catch (err) {
  console.log('failed require my-package');
}

this worked

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