ts-loader ts-loader with Typescript 4.5 beta: "Error: TypeScript emitted no output for .../index.mts"

Anyone have luck webpack-5-ing with the new .mts extension? I'm able to output from tsc -p . fine, but through webpack I'm getting "Error: TypeScript emitted no output for .../index.mts".

Thanks!

    resolve: {
      // Add `.ts` and `.tsx` as a resolvable extension.
      extensions: [".mts", ".ts", ".tsx", ".js"]
    },
    module: {
      rules: [
        {
            test: /(\.mts$)|(\.tsx?$)/,
            use: [
                {
                    loader: 'ts-loader',
                    options: {
                        //transpileOnly: true
                        compilerOptions: {
                            noEmit: false
                        }
                    }
                }
            ]
        }
      ]
    }

Oct 11 '21 19:10 JasonKleban

Haven't tried this at all - am interested with how this pans out!

Oct 11 '21 19:10 johnnyreilly

Yes, I believe it is because of the inclusion of the eventual extension.

import { foo } from "./misc" works as always import { foo } from "./misc.ts" is wrong and gives TS2691: An import path cannot end with a '.ts' extension. Consider importing './misc.js' instead.

but

import { foo } from "./misc.js"; works with tsc but fails only in webpacking with Module not found: Error: Can't resolve './misc.js' in 'C:\example\src' resolve './misc.js'

Does ts-loader need to correct these paths for resolution? Or what?

Oct 12 '21 21:10 JasonKleban

I'm not sure - webpack may need to be configured directly to support modules. Probably worth checking that out first. It may be that ts-loader just works with appropriate config. Or tweaks may be required. Please feel free to investigate; I'll assist where I can.

Oct 13 '21 05:10 johnnyreilly

I suspect this issue may be interesting to you @JasonKleban https://github.com/webpack/webpack/issues/13252

Oct 13 '21 17:10 johnnyreilly

It's possible that @alexander-akait's advice here may be what you need:

https://github.com/webpack/webpack/issues/13252#issuecomment-828584022

Simple: we should not do this https://github.com/TypeStrong/ts-loader/blob/main/src/resolver.ts, instead we should use this.getResolve (simple example https://github.com/webpack-contrib/less-loader/blob/master/src/utils.js#L35), by default you can set extensions: [".ts", "..."], so in future developers don't need to set resolve.extension with .ts extension, it will work out of box.

Plus no problems with future major webpack versions and no need to have enhanced-resolve in deps

Oct 13 '21 18:10 johnnyreilly

I just want to cross-reference https://github.com/microsoft/TypeScript/issues/37582 which is where I redirected https://github.com/microsoft/TypeScript/issues/46344 to. I would love to hear feedback there from Webpack users about

Why do you want/need to use .mts/.cts files?
Do you rely on other node12/nodenext module resolution features like export maps?
Do you have a mix of ESM and CJS dependencies?
Is anyone using Webpack’s resolve.conditionNames and why?
Do you want/need to write import paths with complete file extensions? Why?

Oct 13 '21 18:10 andrewbranch

Thanks @andrewbranch - much appreciated!

Oct 13 '21 20:10 johnnyreilly

@djcsdy - feels like this might be interesting to you given your work on https://github.com/softwareventures/resolve-typescript-plugin

Oct 14 '21 06:10 johnnyreilly

I think we don't need a plugin here, webpack already do the same for cjs/mjs, https://github.com/webpack/webpack/blob/main/lib/config/defaults.js#L490, somebody can shortly write problems places with resolving and what is expected and I will show/send a PR with implement

Oct 14 '21 09:10 alexander-akait

@alexander-akait the issue is that in the new TypeScript module resolution modes, users must write import "./foo.js" even though on disk, the colocated file is ./foo.ts. This is because TypeScript expects TS code to be compiled to JS with these import paths unchanged, that way the output JS will resolve correctly at runtime. But this breaks the expectations of bundlers like Webpack, which does module resolution before a 1:1 TS→JS compilation happens. So the correct specifier for Webpack would be import "./foo.ts" but TypeScript doesn’t allow that. The correct specifier for TypeScript is import "./foo.js" but Webpack can’t resolve that by default.

Oct 14 '21 16:10 andrewbranch

@andrewbranch Thanks

@johnnyreilly Does we support import foo from './test.ts' here before? want to understand how do not break it for other

Oct 14 '21 16:10 alexander-akait

So people don't specify extensions when they're writing TypeScript with ts-loader at present. An import would be extensionless like so:

import { faqsPath } from './misc/FAQs';

Even though the underlying file is FAQs.tsx in this case.

Oct 14 '21 16:10 johnnyreilly

Shorty:

import "./foo" -> based on webpack resolve.extensions logic (now developer uses [ts, 'tsx', ...])
import "./foo.js" -> try to load foo.ts and then try to load using resolve.extensions logic
import "./foo.cjs" -> try to load foo.cts and then try to load using resolve.extensions logic
import "./foo.mjs" -> try to load foo.mts and then try to load using resolve.extensions logic

Also we should respect type in package.json like we do in https://github.com/webpack/webpack/blob/main/lib/config/defaults.js#L491

Oct 14 '21 16:10 alexander-akait

For better setup we can use dependencyType:

typescript-auto
typescript-commonjs
typescript-esm

so developer can setup it better using:

resolver: {
  byDependecy: {
    'typescript-esm': {
      extensions: ['.tsx', '...']
    }
  }
}