Ts-node: probably more correct to prefer ts over js?

[wclr]

If there two files file.js and file.ts both exist, probably ts-node should prefer ts while resolution?

[blakeembrey]

This is out of ts-node control, it's node semantics.

[wclr]

Say in TS file, some.ts and another.ts nearby:

import another from './another' // who resolves `another.ts`?

who resolves (responsible for resolving) another.ts?

[blakeembrey]

I don't understand the question. TypeScript resolves it at compile-time, Node.js resolves it at runtime.

[wclr]

I understand that node does it at run time, so you believe it is not possible to make it check for *.ts first then *.js?

[blakeembrey]

No, it's not. It's possible to mess with the keys so that .ts is first, but I don't think it's a good idea as it impacts everyone else in the ecosystem. In any case, it makes sense to use a compiled file over a uncompiled file.

[wclr]

@blakeembrey what do you think about adding --prefer-ts flag so in require hook for js files it would check if corresponding ts exists and require it instead? I use this approach in ts-node-dev and it works well for me.

[blakeembrey]

It would double every require performance, which isn't something I'd want to do. I also don't understand the benefit still - why would you want to require the TS file when the JS file already exists?

[wclr]

Useful when you may have accidentally (or intentionally for another process) built JS files. Though probably this is caused by my a little bit inconsistent approach when I have a process that should use JS version, and others TS in the same location.

[blakeembrey]

We can do it, though I still remain unconvinced it's a good idea. Are you doing it by messing with the keys?

[wclr]

Are you doing it by messing with the keys?

I don't understand the question)

[blakeembrey]

How are you making ts resolve before js? Are you manipulating the keys of require extensions?

[wclr]

I do in it require extension hook https://github.com/whitecolor/ts-node-dev/blob/master/lib/child-require-hook.js#L57

[blakeembrey]

I see. I wouldn't recommend doing it like that because it breaks some of uses and results in redundant checks. There's also a possible race condition you could remove by doing a try..catch on read instead. The use-case it breaks is related to using the previous loaders. There's a reason we always defer to the previous loader or the existing .js loader instead of reading the file ourselves and it's related to other modules that may want to hook into the module load process.

[wclr]

Ok, actually the solution in ts-node-dev that allows to share ts-node compilation across restarts is really hacky in many ways, though it works for me fine.

[wclr]

There's also a possible race condition you could remove by doing

I thought everthing in sync in require no race conditions, no?

[blakeembrey]

I believe there's always technically there's some processing in between stat and read that can occur in the file being deleted externally (doesn't matter if the JS program is synchronous). Super unlikely to happen. Still easier to do try..catch to avoid an unneeded stat anyway though, since read will throw when the file doesn't exist.

[wclr]

Ok, really this need to be handled.