Replace `preferTsExts` by a smart ordering

[theKashey]

continuation of #837, #529, #648

ts-node has one quite confusing, but quite explainable issue - it adds .ts to the resolve.extensions. However - adds to the end, which breaks code user expectations about how file resolving should work.

So - how it should work

• js should be preferred over ts when preferTsExts is not set.
• ts should be preferred over js when preferTsExts is set.
• 😅ts and js should be preferred over css and less.

How it works

However - the current logic adds ts or after everything, or before everything.

While - should do it relative to js position - just after jsx?, or just before.

The problem

preferTsExts is still not documented, and, honestly, should not be documented. It shall work out of the box. 5 months ago, when I run into the issue, I've resolved it by manually hoisting extensions, hopefully, it's now supported out of the box.

But the problem is not closed unless default behavior is broken.

What would you say about changing this moment? js and ts should be in one "group", so let's make it a bit more "smart".

[blakeembrey]

I don't have any desire to implement it out of the box. I believe it'll open a larger class of bugs related to ts-node. For example, if .ts resolves before .js, every node_modules will be loading .ts files first and breaking on 1. TypeScript not compiling it and 2. even if ts-node did compile it, it will break because of differences in tsconfig.json files.

To get around this, ts-node could manually check if you're in node_modules and if a .js file exists instead, then load the .js file for you magically. This needs to work as expected with the ignore configuration too. It's honestly just not a high enough priority for me to take on this work when very few people request this. If you really want this, I'll need examples that refute my concerns above (e.g. examples of projects that require packages written in TypeScript and publish .js and .ts files next to each other).

[blakeembrey]

Also, it's definitely documented in the README 😄

[theKashey]

That was not only .ts, but also about .css and other extensions. As far as I remember our problem was Component.tsx and Component.less - while webpack was resolving everything correctly - ts-node was picking Component.less as long as .less comes before .ts in the resolution order.

So - I am not asking to hoist ts over js - I am asking to put them next to each other - ['js', 'jsx', 'ts', 'tsx'] and only then - .css and so on.

[blakeembrey]

That’s related to the order you add these extensions. If you put things in the order you want when you register, this won’t be a problem. It feels like too much magic for this module to maintain when the solutions are fairly straightforward.

[theKashey]

Then ts-node is going to have undefined behavior, as long as:

• in one case, .css, or any other legit extension would have priority over ts, so once you migrate your codebase from js to ts - it stops working.
• in another case, ts would be more important as js, and For example, if .ts resolves before .js, every node_modules will be loading .ts files first and breaking on 1.

However, a solution using a third-party module to reorder extension resolvers was provided in the initial messages. ts-node don't have to implement it.

[blakeembrey]

Isn't your points above the reason ts-node shouldn't be doing this itself? I'm not sure how it's undefined behavior though, it's well-defined - extensions are ordered in the order they're registered. I agree this should be done externally to ts-node as a general solution, but also believe in your example of .css and .ts, you could just re-order where you register extension instead of messing with object key ordering. Of course this is all a very general discussion without any examples, and your original report ask to make .ts ordered first by default.