Make `--script-mode` default behavior

[cspotcode]

Relevant discussion starts here: #939 (comment)

TODO/note to self: copy the important bits into a summary, here

This ticket is to research whether or not --script-mode should be the default behavior of ts-node.

[blakeembrey]

Great question, I can't think of any reason this wouldn't be a good idea right now. The default behavior uses findConfig so for personal usages it's usually something like ts-node src/index.ts and this would continue working (though the change is a breaking change for others).

[Livven]

Discovered this option from the 8.7.0 changelog and it's exactly what I wanted but didn't know existed. Makes working with a folder of TS utility scripts that need a separate tsconfig.json much easier, as #939 (comment) notes, as it allows you to run a TS script from any working directory with the same tsconfig.json.

For backwards compatibility I think these would be the different scenarios:

• calling a file in the current working directory: no change
• calling a file in a subfolder: breaking change if there is another tsconfig.json in the subfolder, but if you have that I'd say your fault
• calling a file in a parent folder: always breaking change, but, I mean, how dare you

So overall, should definitely be a major version bump, but probably the right choice.

[cspotcode]

The language service supports multiple tsconfig files at once, if they're in multiple subdirectories, right?

For example, given a monorepo like this:

./packages
 ./foo
 tsconfig.json
 index.ts
 ./bar
 tsconfig.json
 index.ts

I think my editor's language service will treat these 2 subdirectories as different projects with different tsconfigs and handle them correctly. I don't think I need to set up a root tsconfig with "composite": true and references, either; it works automatically. EDIT this is accurate based on a quick test in VSCode

Should we be doing the same? So if I run ts-node-script ./packages/foo/index.ts and it does require('../bar/index'), should we compile bar/index.ts using compiler rules from bar/tsconfig.json?

[Livven]

I believe this is editor-specific behavior that is not actually reflected by tsc, which only allows one tsconfig except via inheritance with the extends key (or apparently with project references but that is another matter).

Consider that an editor cannot actually know how you'd invoke tsc and thus which tsconfig you would actually use; you can specify an arbitrary tsconfig.json via --project so what VS Code does here is simply a best effort guess in order to provide a good editing experience.

In other words, if you were to use tsc with that setup it would not merge both tsconfigs, from my understanding.

[cspotcode]

It sounds like you are saying we should support project references, but should not magically pick up other tsconfig files based on where a require()d script is located. Is that correct?

Building on my example above, assuming each tsconfig.json has "composite": true with a "references": [{}] referring to the other tsconfig.json.

When I run ts-node --script-mode ./packages/bar/index.ts:

• ts-node will load ./packages/bar/tsconfig.json and (via reference) ./packages/foo/tsconfig.json
• ts-node will compile ./packages/bar/index.ts according to ./packages/bar/tsconfig.json
• bar/index.ts requires ../foo/index.ts
• ts-node will compile ./packages/foo/index.ts according to ./packages/foo/index.ts

[Livven]

I'm not familiar with the project references or composite feature, I just wanted to point out that you probably shouldn't draw any conclusions on how to resolve the tsconfig.json based on what an editor does 😉

but should not magically pick up other tsconfig files based on where a require()d script is located

Agree with this, as I believe tsc doesn't do this either.

[cspotcode]

Ok, thanks for clarifying. Interestingly, ts-node uses the LanguageService internally, which is the same component of typescript that drives in-editor experiences. So our behavior is like a hybrid between tsc and an editor.

[KasparEtter]

I don't feel qualified enough to judge the technical implications of such a change but from my personal experience as documented in #995 I vote in favor of this in order to better match user expectations.