Consider using jiti for typescript loading instead of ts-node

[timofei-iatsenko]

FYI
lingui/js-lingui#1474

[Codex-]

Thanks, I'll have a look into it.

The problem I had with using the tsc API directly was that it transformed without enforcing the type system when used how they recommended lol.

I was also following the progress of both @swc for enforcing types, and stc too.

[timofei-iatsenko]

The main point of switching from ts-node (or at least changing the way it works) is not in the type system.

The current trend of ecosystem is transpiling should be done separately from type checking, because the second is very slow.

For the use cases which cosmiconfig trying to tackle, i don't think type checking ever needed.

The main problem with current implementation is that ts-node registered process-wide. That causes the following issues:

• if in the host application / library happened to call to TypescriptLoader more than once ts-node get registered more than one time too. It causes one, two, ten, and more compilation of the files (not only a config, read following!).
• When ts-node get registered it affects all following require calls, not only requires from config:

   - load cli util (host)
   - load config using TypescriptLoader
      -- (ts-node get registered)
      -- load imports tree from config (go through ts-node)
   - continue loading cli util (go through ts-node) <--- shouldn't be, because it take time!
  

Jest for example, solve second problem by (pseudocode):

"ts-node".register()
loadConfig("jest.config.ts")
"ts-node".register(false)

But this works on assumptions. They assume config would not have function which would be called after config initialization.

Example:

// my.config.ts
module.exports = {
  [...]
  someFn: async () => {
      const file = await import("./another-file.ts")
  }
}

Then if we do as Jest:

"ts-node".register()
const config = loadConfig("my.config.ts")
"ts-node".register(false)

// ------

await config.someFn() // <!-- Error here, ts-node already disabled at this point, so import another `ts` file would fail.

So Jest-way is not suitable for all projects.

Jiti unlike ts-node was created for such cases and should transpile only one branch of requires.

 - load cli util (host)
 - load config using Jiti
    -- Separate VM created
    -- load imports tree from config in separate VM <- go through Jiti
 - continue loading cli util <- not affected by Jiti

[Codex-]

The main point of switching from ts-node (or at least changing the way it works) is not in the type system.

The current trend of ecosystem is transpiling should be done separately from type checking, because the second is very slow.

Sure, that's a given, but my point is that changing the behaviour from enforcing types to not enforcing types is a pretty significant change for a package like this.

The expectation has already been set, by it's messy history.

For the use cases which cosmiconfig trying to tackle, i don't think type checking ever needed.

I don't disagree here, the type-checking should ideally be the concern of the consumer, and suit the needs of their own repositories usage of TS. We don't currently have that luxury.

So Jest-way is not suitable for all projects.

Completely agree.

Jiti unlike ts-node was created for such cases and should transpile only one branch of requires.

 - load cli util (host)
 - load config using Jiti
    -- Separate VM created
    -- load imports tree from config in separate VM <- go through Jiti
 - continue loading cli util <- not affected by Jiti

Jiti seems reasonable, but it is not equivalent to the current behaviour.

At nearly 4 million weekly downloads, making drastic and fundamental behaviour changes could result in numerous issues for consumers that expect the current behaviour.

However, in saying that, with a major version bump I could look into providing options to satisfy both cases with optional peer dependencies and explicitly specifying a setting to use the ts-node behaviour, otherwise use something like Jiti to perform a simple transpile.

[olawalejuwonm]

Does jiti transpile-only without type checking?

[Codex-]

@olawalejuwonm the types should be enforced,

cosmiconfig-typescript-loader/lib/loader.spec.ts

Line 38 in ae3be22

it("should fail on parsing an invalid TS file", () => {

But in saying that, this test mainly pertains to transpiling invalid js too, so if you have a case where its not working as expected please open an issue with the case and I'll look into it

[olawalejuwonm]

I don't want it to type check @Codex-

[Codex-]

@olawalejuwonm why would you use the typescript loader if you don't want to use types? If there is an actual problem with using the ts loader as intended please open an issue with reproduction steps.