another workaround I found was using NormalModuleReplacementPlugin to replace the problematic extension

 module.exports = function (env) {
  return {
    plugins: [
      new webpack.NormalModuleReplacementPlugin(new RegExp(/^\..+\.js$/), function (resource) {
        resource.request = resource.request.replace(new RegExp(/\.js$/), '');
      }),
        }
      ),
    ],
  };
};

in our case, this did the trick

Updated with the RegExp suggested by @laverdet https://github.com/webpack/webpack/issues/13252#issuecomment-1185674918

another workaround i found was using NormalModuleReplacementPlugin to replace the problematic extention

 module.exports = function (env) {
  return {
    plugins: [
      new webpack.NormalModuleReplacementPlugin(new RegExp(/\.js$/), function (resource) {
        resource.request = resource.request.replace('.js', '');
      }),
        }
      ),
    ],
  };
};

in our case this did the trick

I tweaked the RegExp here because otherwise imports to modules like sha.js will fail. Thanks!

            new NormalModuleReplacementPlugin(/^\..+\.js$/, resource => {
                resource.request = resource.request.replace(/\.js$/, "");
            }),

I think we can close it, now we have extensionAlias - https://webpack.js.org/configuration/resolve/#resolveextensionalias

Something like that could be solved in a custom resolver plugin. I think think this typescript-specific problem fits into the webpack core.

The resolver plugin could take an extensions argument which is a list of typescript extensions that should be tried when the request ends with .js.

Use extensionAlias in Next.js via experimental.extensionAlias config introduced in https://github.com/vercel/next.js/pull/45423:

next.config.js

/** @type {import("next").NextConfig} */
const nextConfig = {
  experimental: {
    // Remove .js from import specifiers, because
    // Next.js and webpack do not yet support
    // TypeScript-style module resolution out of the box
    // https://github.com/webpack/webpack/issues/13252#issuecomment-1171080020
    // https://github.com/vercel/next.js/pull/45423
    // https://github.com/vercel/next.js/issues/58805
    // https://github.com/vercel/next.js/issues/54550
    extensionAlias: {
      '.js': ['.ts', '.tsx', '.js', '.jsx'],
      '.jsx': ['.tsx', '.jsx'],
      '.mjs': ['.mts', '.mjs'],
      '.cjs': ['.cts', '.cjs'],
    },
  },
}

module.exports = nextConfig

Yeah, sometimes I think npm should not allow to use . in a package name, because it is pain to write regexp and code looks misleading:

var shajs = require('sha.js')

Do we load ./sha.js or ./sha.js/index.js? weird

not stale

The problem is that using the fully-specified .js extension fails when using TypeScript .ts files (they are not resolved in parity with the behavior of TypeScript and tsc)

With TypeScript and tsc, the following works:

// index.ts
import {abc} from './abc.js';

// abc.ts
export const abc = 1;

With webpack, it fails and cannot resolve the ./abc.js specifier (note the difference between the extensions - .js and .ts).

See @RyanCavanaugh’s comment here: https://github.com/microsoft/TypeScript/issues/41887#issuecomment-741968855

TypeScript doesn’t modify JavaScript code you write, the import path you write should be the one you want to appear in the output .js file

Oh sorry, deleted my comment now! Indeed the type is there in 5.74.0, somehow one of my webpack versions was locked to 5.73.0 😬

@iamWing the /^\..+\.js$/ regex seems to work for ./app.js, and it is intended to filter out sha.js:

> /^\..+\.js$/.test('./app.js')
> true

another workaround i found was using NormalModuleReplacementPlugin to replace the problematic extention

 module.exports = function (env) {
  return {
    plugins: [
      new webpack.NormalModuleReplacementPlugin(new RegExp(/\.js$/), function (resource) {
        resource.request = resource.request.replace('.js', '');
      }),
        }
      ),
    ],
  };
};

in our case this did the trick

I tweaked the RegExp here because otherwise imports to modules like sha.js will fail. Thanks!

            new NormalModuleReplacementPlugin(/^\..+\.js$/, resource => {
                resource.request = resource.request.replace(/\.js$/, "");
            }),

The regex on the tweaked version doesn’t seem right to me. Neither _/app.js or sha.js matches the expression.

My suggestion would be use /.*\/+.+\.js$/ instead. Matching a / character in the middle of the path can help identifying if we’re importing a local module or not, because if we’re importing a dependency installed we usually just write import something from 'something';, but if we’re importing a local module, we write import something from './path/something.js'.

A better way to cover all cases would be tweaking the function in NormalModuleReplacementPlugin to exclude some patterns for the edge cases.

e.g.

new NormalModuleReplacementPlugin(/.*\/+.+\.js$/, (resource) => {
  if (/^sha\.js$/.test(resource.request) return; // - Exclude the edge cases using if statement
  resource.request = resource.request.replace(/\.js$/, '');
}),

Maybe we can also develop a plugin to do what we’re doing with NormalModuleReplacementPlugin here but also check the dependency list from package.json so that all packages listed there can be excluded automatically? I’ll do some research on this later.

Edited for typo

technically we can add this to default rules but webpack doesn’t support ts out of the box… so probably you will need specify extension alias

Accidentally close, yes, you can specify extensionAlias in the resolve option (https://webpack.js.org/configuration/resolve/), like you do it for alias/etc

just one line

Ok, so what is the configuration that would be required? I’m sure that this will be a common question for those looking to take advantage of this.

What I can see from the PR is something like this:

{
  "extensionAlias": {
    ".js": [".ts", ".js"],
    ".mjs": ".mts"
  }
}

Is extensionAlias a valid top-level key in webpack config? Or does enhanced-resolve need to be added via a plugin or something in the config as well?

should be fixed by https://github.com/webpack/enhanced-resolve/pull/351

@karlhorky It is not implemented in enhanced-resolve (we should start with it), but it is easy https://github.com/TypeStrong/ts-loader/issues/1383#issuecomment-968075478, just want to verify @sokra and @vankop are supporting my idea

@karlhorky I think we need a plugin in https://github.com/webpack/enhanced-resolve/ (I already implemented it in thread) and allow customize resolver, allow ts-loader can create custom resolver using loader API and supports it out of box

Simple workaround for your simple case:

resolve: {
    alias: {
      './test.js': './test'
    },
    extensions: ['.tsx', '.ts', '...'],
},

Ideally ts-loader should respect resolve.extensions (better resolve.byDependency.typescript) and when you using import something from './foo.js' try to resolve ./foo.js as ./foo.tsx/./foo.ts and then other variants (i.e. ./foo.js and etc).

To avoid collisions between ts-loader resolving and Node.js resolving we should support https://webpack.js.org/configuration/resolve/#resolvebydependency, so you will use:

resolve: {
  byDependency: {
    typescript: {
      extensions: ['.tsx', '.ts', '...'],
    },
}    

It will be implement using https://webpack.js.org/api/loaders/#thisgetresolve, we use the same logic for sass/less/etc so @import with CSS and SASS works good.

Honestly it’s not hard to do.

Yep, I see…

[tsl] ERROR in /home/path/to/webpack-babel-test/src/index.tsx(1,22)
      TS2691: An import path cannot end with a '.tsx' extension. Consider importing './test.js' instead.

We need improve it on ts-loader side, webpack works correctly here.

I think in ts better to have ts extension at the end, it is fully-specified import

The TypeScript team doesn’t agree, check out the issue I linked above: https://github.com/microsoft/TypeScript/issues/41887#issuecomment-741968855

What is problem with webpack here? If you use import you need to write extension, or disable fully-specified ESM import, don’t know what we should fix here…