Fix: Use rewritten cosmiconfig-typescript-loader package for handling TS config files.

[Codex-]

I've rewritten and published a replacement for the original cosmiconfig-typescript-loader package which addresses a number of issues reported on that original repository:

• #134: "Doesn't work with Cosmiconfig sync API"
• #147: "doesn't provide typescript, requested by ts-node"
• #155: "Misleading TypeScriptCompileError when user's tsconfig.json "module" is set to "es2015""

The main issue I was experiencing was the issue where cosmiconfig only works with transpiled modules that target commonjs, which is addressed with the replacement package. This issue is present with the current copied ts-loader code in craco.

See here for more details: https://github.com/Codex-/cosmiconfig-typescript-loader

[patricklafrance]

Before merging this PR, I would like to have your opinion @alvis.

[Codex-]

I've tested this on my own usage of craco, but it would be great to have some additional sanity tests done too 👍

[alvis]

Hi @Codex- Thanks for making cosmiconfig-typescript-loader. It's always good to someone to step up and improve the original unmaintained loader. 👍🏼

However, there are few points I'm not sure adopting cosmiconfig-typescript-loader here is good move.

• #134 was a problem and it has been fixed in fix: load ts config file synchronously #344
• #147 is not a real problem of the original loader. If you write in typescript, you need to have typescript to be installed as your devDependency anyway.
• #155 I'm not sure the current implementation is a robust solution. On https://github.com/Codex-/cosmiconfig-typescript-loader/blob/8fa43b6f3781d70e0019395a288a7bb92ee14ed3/lib/loader.ts#L9, non commonjs module (e.g. es2015 or esnext) was made to work by overriding the value to commonjs for ts-node. From a build tool perspective, I think it's okay but I'm not sure if will create any conflict with other build tools.
• As far as craco concern, the current implementation introduced by fix: load ts config file synchronously #344 is simpler and other issues solved by cosmiconfig-typescript-loader don't apply to craco.

[Codex-]

It's worth noting that the current implementation introduces a dependency on ts-node without explicitly adding it as a package dependency, so it is depended upon implicitly and can fail in repositories that do not have this dep present.

Craco now also suffers from #155. If it's not CJS, then consequently it is not compatible with the current implementation of cosmiconfig.

Pick your poison I suppose. The REPL for this build context should be fine, you're already registering the REPL anyway and the config used by default (with how tsconfig resolution is handled) in the case of esm is not compatible with cosmiconfig.

I explored using ts-nodes REPL and the TS service but ended up in a scenario that was rapidly growing unruly lol. There's extensive discussion about multiple registrations of ts-node.

[alvis]

It's worth noting that the current implementation introduces a dependency on ts-node without explicitly adding it as a package dependency, so it is depended upon implicitly and can fail in repositories that do not have this dep present.

Thanks for pointing out. It's true and it's a mistake should be fixed.

Craco now also suffers from #155. If it's not CJS, then consequently it is not compatible with the current implementation of cosmiconfig.

Though I'm not sure if overriding is the best solution, but I agree the current implementation requires module in tsconfig to be set to commonjs, or require users to use a separate tsconfig.json with commonjs module for building.

For these reason, I'd say it's worth switching to cosmiconfig-typescript-loader. :)

[Codex-]

Is there anything else I can do to help facilitate getting this through? 😄

[alvis]

LGTM :)

[patricklafrance]

Merged, thank you @Codex- :)

[patricklafrance]

Available in https://www.npmjs.com/package/@craco/craco/v/6.4.3

[Codex-]

Great, thanks!

[seanblonien]

So we have to use npm 7 or greater now?

I would love too but one of my dependencies has a breaking peer dependency specificity that prevents me from upgrading NPM versions. Guess I'll be on Craco 6.4.2 until then

[Codex-]

So we have to use npm 7 or greater now?

Nah, just the defaults. Since >=7 introduces v2 of package lock I had it set to that but have lowered it so it shouldn't throw a warning for you now.

I've cut a release now that should fix your issue, if you find you're still hitting 1.0.1 then remove craco and re-add it to resolve the new version.

[seanblonien]

Apologies, what release version fixes this issue/how do I get that version?

[Codex-]

@seanblonien if you install the latest version of craco, 6.4.3, you will get the latest version of cosmiconfig-typescript-loader.

You can see it in your lock:

    "node_modules/cosmiconfig-typescript-loader": {
      "version": "1.0.2",
      "resolved": "https://registry.npmjs.org/cosmiconfig-typescript-loader/-/cosmiconfig-typescript-loader-1.0.2.tgz",
      "integrity": "sha512-27ZehvijYqAKVzta5xtZBS3PAliC8CmnWkGXN0vgxAZz7yqxpMjf3aG7flxF5rEiu8FAD7nZZXtOI+xUGn+bVg==",

If you find installing the latest craco does not pull this version, you will have it in your lock already, but this can be cleared by simply removing craco from your package, installing, then adding it back.

[seanblonien]

Ahh it was a transitive dependency change/fix, that makes more sense. Thanks for fixing and explaining to me!

It's working now ❤

[nmoinvaz]

With this change I am now getting these warnings during yarn install:

warning "@craco/craco > cosmiconfig-typescript-loader@1.0.4" has unmet peer dependency "@types/node@*".
warning "@craco/craco > cosmiconfig-typescript-loader@1.0.4" has unmet peer dependency "typescript@>=3".
warning "@craco/craco > cosmiconfig-typescript-loader > ts-node@10.4.0" has unmet peer dependency "@types/node@*".
warning "@craco/craco > cosmiconfig-typescript-loader > ts-node@10.4.0" has unmet peer dependency "typescript@>=2.7".

[Codex-]

If you're not using typescript / ts based config files you can disregard these, yarn also provides means to filter logs you're not interested in: https://yarnpkg.com/configuration/yarnrc#logFilters