Fix #1004: resolve config relative to realpath of entrypoint

[cspotcode]

Fixes #1004.

[blakeembrey]

I think I’d be more comfortable noting that we only support symlinked directories instead of doing this, but up to you. If we only support directories it would become easy. Alternatively we can implement the resolver in a loop ourselves instead of messing with require.

[blakeembrey]

We might not even have TSX, JSX support extensions added either, so it’s another difference here. You could expose the function that creates a list of extensions, then just loop over that list and resolve like node.js does since we don’t need the extra require logic.

[cspotcode]

Do we need to support loading a directory containing an index.* file, or a directory containing a package.json with a main field pointing to another file? E.g. require('./directory-containing-package-json')?

The chicken-and-egg problem with file extensions is a real bummer. I'll try to come up with some realistic examples of this causing problems in real life.

The only reason I was hoping to support symlinked scripts is so they can be put on the PATH. npm and yarn do this a lot, and I can see it coming up in monorepo situations. (lerna, yarn2)

[cspotcode]

Here is my analysis for if --script-mode ambiguous config resolution will be a problem in real-world scenarios.

Things we don't know that make it ambiguous

• whether or not .tsx or .jsx are enabled
• whether .ts(x) takes precedence over .js(x)

When resolution might match 2x different files, we may follow the wrong one, which may lead us to discover the wrong config.

Ways ambiguity can happens

• 2x matched files are peers of each other, e.g. ./somedir/foo.jsx and ./somedir/foo.ts, and symlink to different target directories
• file is peer with directory of the same name, e.g. /somedir/foo.tsx and /somedir/foo/package.json

Contrived examples

• foo.jsx and foo.ts peers in same directory, symlinked to different target directories. preferTsExts and allowJs determine which one is resolved.
  • This seems extremely rare. Sure, peers might exist, but they either wouldn't be symlinks, or they'd point to the same target directory
• foo.jsx and foo/ in same location. Do we look at foo.jsx or foo/index.*, or whatever foo/package.json says? (foo.jsx takes precedence, but jsx might not be enabled)

Real-world examples

None

I can't think of a real-world situation where the contrived examples will occur.

Mitigation strategies

Based on the above, I don't think ambiguity is a real problem. But if we want to avoid issues, here are a few strategies:

• Do not support symlinked files, only symlinked directories

  • Breaks the npm link use-case
  • May break monorepos (yarn 2 and lerna) where one local package exports binary executed by others via package scripts?

• Detect and throw an error whenever ambiguity affected config resolution

  • Throw when directory we resolve initially for config discovery is different than directory resolved to run the script (in all other cases, ambiguity has no real effect)
  • When anyone hits ambiguity in the real world, we will get a ping on our issue tracker
  • Only do this test when TS_NODE_DEBUG is enabled, to avoid impacting performance?

• Do nothing; allow ambiguity

  • Affected users can specify full path to avoid ambiguity