ts-loader: Module not found for TypeScript 4.7

hm, why don’t use https://webpack.js.org/configuration/resolve/#resolveextensionalias? I think it will work

https://github.com/microsoft/TypeScript/issues/49083#issuecomment-1200999574

🎉

https://github.com/justland/just-web/pull/58

One update. After I add the cjs/package.json workaround, at least the CommonJS side resolution is working fine. It’s not directly related to this issue, but it shows that having due-export (CJS + ESM/NodeNext) able to work at the end application.

I have published color-map with a few variations to test this:

• 1.1.4: original, with main, module, jsnext:main: (https://github.com/unional/color-map/blob/v1.1.4/package.json)
• 2.0.0: ESM only, build with module: esnext and module resolution node (https://github.com/unional/color-map/blob/v2.0.0/tsconfig.esm.json)
• 2.0.1: ESM only using NodeNext (https://github.com/unional/color-map/blob/v2.0.1/tsconfig.esm.json)
• 2.0.2: export with exports.require (https://github.com/unional/color-map/blob/v2.0.2/package.json)
• 2.0.3: export with ESM and main (https://github.com/unional/color-map/blob/v2.0.3/package.json)

upgrade to 4.7.3 (including test pack) complete

I’m open to adjusting this - I mostly care that code is formatted consistently. If there’s DX tweaks you have in mind we can look at it.

#1477 is the PR for that.

https://github.com/TypeStrong/ts-loader/issues/1464

It looks like the npm that ships with node 18 had some breaking changes. We use yarn 1 for ts-loader anyway, so I’d advise sticking with that

🤣 that’s why. Only running comparison tests on Windows. I was running yarn test, i.e. also running execution-tests

I see. I can take a look at it. 😃

Sounds good - when you get to it, feel free to stick up a work in progress PR with broken tests if needs be. Will be happy to pair on this

Apologies if I only reply occasionally - I’m on holiday

NP. That explains all those nice pics. 🌷

Yeah, I can give it a shot. But need to handle a few things first. Will see if I can get to it. 😃

Roughly the three major bits of NodeNext / mts / cts support in ts-node were:

Replace node’s resolver with one that checks what I call “alternative file extensions.” Every time node’s resolver would check for foo.js, also check for the alternatives: foo.ts, foo.tsx, foo.jsx

Teach transpiler codepaths to emit Typescript’s 2x new flavors of module:

• nodenext-flavored CommonJs, like commonjs emit except that now dynamic imports are preserved
• nodenext-flavored ESM, like EsNext emit except that now import foo = require('foo') statements automatically use createRequire to gin up a require function

ts.transpileModule does not expose this functionality; cannot be used

Teach transpiler codepaths to classify files as either CJS or ESM using the same rules as NodeNext

• So, use file extension and contextual package.json to decide which of the 2x flavors to emit
• TypeScript relies on its own resolver to do this classification; transpile-only codepaths need to reimplement it