TypeScript imports with .js file extensions don't work

[justinfagnani]

Bug report

Describe the bug

When importing a TypeScript module from another, TypeScript allows the use of the .js file extension:

foo.ts:

export const foo = 42;

bar.ts

import {foo} from './foo.js'

This is important in plain TypeScript projects because browsers don't do any module resolution and require the correct extensions. The compiled output works as it.

If you copy the same files into a Next.js project you will get a compile error that foo.js cannot be found.

To Reproduce

See above

Expected behavior

No compile errors

System information

• OS: macOS
• Version of Next.js: 9.1.2

[Timer]

Hey @justinfagnani! Thanks for letting us know about this issue.

I wasn't aware TypeScript allowed for this behavior. What happens when a .ts and .js version exist, do you know which it prefers?

Are there any other toolkits that support this behavior out-of-the-box? We'd love to see a reference implementation.

We'll explore the above questions if they're more nuanced when we get around to implementing this.

Feel free to send a PR as well!

[jeremy-coleman]

@Timer ts prefers ts and will ignore the js file when both are present, you can confirm with tsc -w without an outDir specified and changing the contents of the .js file - it won't recompile.

to get this working in next, i think https://github.com/tleunen/babel-plugin-module-resolver/blob/master/src/resolvePath.js has everything you need

[lifeiscontent]

seems that next.js prefers .ts files in node_modules folder over .js files as well, in a library I'm writing in TS which I build all my typescript files to js in the same folder, next.js starts crawling the node_modules directory for types and throws an error because I have a babel plugin that processes SVG and typescript doesn't know what it is.

[PabloSzx]

any news on this?

[samfortunato]

👍 ing the importance of this issue. Not sure how strictly Next.js uses the feature request label, but I would argue that this should be expected behavior, not an added feature:

• TypeScript has allowed .js extensions in import statements since version 2.0 (September 2016). Using TypeScript in Next.js should follow users' expectations when using TypeScript: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-0.html#module-identifiers-allow-for-js-extension

• The official spec of ECMAScript modules uses a URL as the module specifier (I think "bare specifiers", i.e. module names without extensions, are being worked on). Next.js shouldn't go against ECMAScript standards: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#importing_features_into_your_script

As an aside, some devs may have settings in their IDEs that auto-add .js to the end of their imports, to easily use ECMAScript modules/support the new spec. Modifying IDE config or dev workflow to go against spec for one library is not a good dev experience.

[dzek69]

If anyone is looking for copy-paste workaround here it is:

1. install babel-plugin-module-resolver (at the time of writing im using 4.1.0)

2. create babel.config.js (if you already have it you will have to adjust it of course) and put this inside:

const path = require("path");
const fs = require("fs");

module.exports = {
    presets: ["next/babel"],
    plugins: [
        [
            "module-resolver",
            {
                extensions: [".js", ".jsx", ".es", ".es6", ".mjs", "ts", "tsx"],
                resolvePath(sourcePath, currentFile, opts) {
                    if (!sourcePath.startsWith("./") && !sourcePath.startsWith("../")) {
                        return sourcePath;
                    }

                    if (sourcePath.endsWith(".js")) {
                        const relPath = path.resolve(path.dirname(currentFile), sourcePath);
                        const tsPath = relPath.replace(/\.js$/, ".ts");
                        const tsxPath = relPath.replace(/\.js$/, ".tsx");
                        if (fs.existsSync(tsPath)) {
                            return tsPath;
                        }
                        if (fs.existsSync(tsxPath)) {
                            return tsxPath;
                        }
                    }

                    return sourcePath;
                },
            },
        ],
    ],
};

I'm using that for few months already without any issues.

I'd love to have this working without a workaround though. @samfortunato gave some nice arguments why.

[samfortunato]

@dzek69 Awesome, that did work. Was looking for a solution like this before.

Unfortunately, it means Next.js will not use the new Rust compiler. Would have to look at the SWC docs to see if a workaround could be configured in the same way...

[jameshfisher]

"TypeScript allows the use of the .js file extension" is downplaying the importance of this bug. In fact, TypeScript recommends the use of the .js file extension:

• See examples at https://www.typescriptlang.org/docs/handbook/2/modules.html
• Compiled JavaScript import is missing file extension microsoft/TypeScript#40878
• [FEATURE] absolute->relative module path transformation microsoft/TypeScript#15479 (comment)

My Next.js application is not an isolated project; it shares TypeScript modules with other environments that rely on this .js file extension. Until Next.js fixes this issue, I cannot write TypeScript that works outside of Next.js.

[ifiokjr]

Jumping in to say that this is an important feature to add.

[jameshfisher]

Why is this a "discussion" and not an issue? It's a straightforward bug, and I don't see much discussion required. If there is none, can we convert it back to an issue?

[justinfagnani]

I filed it as a bug 🤷

[hornta]

I just stumbled upon this myself and the documention for this module-not-found error didn't mention it. I think it's worth mentioning it in https://nextjs.org/docs/messages/module-not-found

[AverageHelper]

Just popping in to say I'm seeing this behavior as well, under Vercel CLI v28.4.5 and typescript v4.8.3: Vercel seems to not traverse imports that end in .js the way Node would after transpiling the TypeScript. Removing the file extension "fixes" the issue, but means that I must now rewrite all of my imports.

I've been migrating my back-end codebase from Express, where previously I'd transpiled TypeScript to ESM JavaScript, where TypeScript all but requires the .js extension. Node under CommonJS does not care about that extension at the moment. Now it seems that Vercel cares deeply about that extension, despite transpiling to CommonJS.

[a-type]

This is a pain! I have a large project written in ESM/ Vite that I'd like to port to NextJS, but it would require rewriting every single import, which had to be .js because that's how ESM/{ "type": "module" }/{ "resolution": "NodeNext" } works. This limitation makes NextJS feel like a weird, bespoke ecosystem.

[slimshreydy]

Just ran into this issue too. Quite frustrating.

[michaelhays]

I haven't tested this thoroughly, but it looks like with the new allowImportingTsExtensions TypeScript setting, you can now import other files using the .ts extension!

[callumgare]

I believe I have a workaround for this that doesn't involve using babel. In your next.config.js file add:

    webpack: (config) => {
        config.resolve.extensionAlias = {
            ".js": [".ts", ".tsx", ".js"],
        };

        return config;
    },

With that it should be possible to have files ending in the .ts/.tsx extension, use the .js extention in import paths for them (inline with typescript recommendations) and set "type": "module" in package.json.

Note that this requires the latest version of Next.js and webpack (or at least webpack v5.74.0) since extensionAlias was only introduced recently.

[c100k]

This workaround doesn't seem to work on my side in a specific case : when the file is imported into a file that is itself imported via an alias path.

@my-alias => my-alias/index.web.js => ./component/Index.js 💣

Or maybe I'm missing something ?

[scinscinscin]

I've had good luck getting things working with workaround 2 from this related github issue.

[GervinFung]

This issue is important, which is why ts-add-js-extension was made, the strength of this package is that, it can find whether you are importing/exporting something.js or something/index.js, and it can find whether you are importing/exporting .js or .mjs, you just have to specify the outDir for this package to work, I try not to bind this tool on tsc or anything related to it (reading outDir in tsconfig.json) and want it to be able to run without it. Try it, it should solve your problem

[CMCDragonkai]

Was there ever solved? @callumgare gave a workaround using webpack config. But nextjs13 is using turbopack now...?

[CMCDragonkai]

It appears to work atm. Perhaps turbo isn't enabled atm.

[ajwootto]

I re-opened this as a bug issue here, since it doesn't seem like it's a "discussion":
#59744

Some additional colour that I've found when working with this is that ES module 3rd party libs that are used in Pages router serverside code seem to require the .js extension in their source files because they use the Node ESM resolver under the hood. If you are making a Next library with ESM for use in the pages router, you have to add the extensions.

However, you also can't add the same extensions to any application code in your main Next app, otherwise it can't resolve the file.

Furthermore, to publish a server action in a 3rd party lib for the App Router, the package currently needs to be ESM because the Next bundler adds ES module syntax to any server action file that is imported. If the package is distributed as CommonJS then the build fails when importing a server action from that library.

So I'm currently stuck in a situation where my Next library that needs to work in both pages and app router, and contains a server action, has to be published as ESM and thus has to include the .js file extension, but the library's source files cause build errors when linked directly into a Nest application because the .js extension is invalid in that context.

[orthinkzai]

did you find a solution or a workaround? I am stuck too

[dzek69]

@orthinkzai
If you are looking for fixing imports of your own files having .js extension I posted working solution here: #32237 (comment)

This falls back to Babel however. If you only need to "fix" "broken" packages, that have invalid imports inside them use https://nextjs.org/docs/app/api-reference/next-config-js/transpilePackages

If you want to use both fixes at the same time and you are on older version of next.js use this: https://www.npmjs.com/package/next-transpile-modules

[SanjoSolutions]

With Webpack this can be fixed with the following next.config.mjs:

/** @type {import("next").NextConfig} */
export default {
  webpack: webpackConfig => {
    webpackConfig.resolve.extensionAlias = {
      '.js': ['.ts', '.js'],
      '.mjs': ['.mts', '.mjs'],
      '.cjs': ['.cts', '.cjs'],
      '.jsx': ['.tsx', '.jsx'],
    }

    return webpackConfig
  },
}

[KoTTi97]

Has anyone figured out how/if this works when using turbopack (next dev --turbo)?

[samfortunato]

has this really not been fixed yet? imports with .js extension are part of ECMAScript standard, no?

[drewbaker]

Just ran into this today with "lodash-es": "^4.17.21". I couldn't use the functions like this:

import snakeCase from 'lodash-es/snakeCase';

I had to do like this:

import snakeCase from 'lodash-es/snakeCase.js';

Took about 30mins to figure out...

[dzek69]

@drewbaker that's the opposite of what we talk here. We're talking about imports with .js not working :)

Also remember that paths in modules may not be even "real" paths thanks to "exports" field in package.json. That's not the case with lodash-es however.

[PaulRBerg]

It's August 2025 and this still isn't fixed

This makes it impossible to use Next.js in a monorepo that uses .js imports.

[dzek69]

There are working workarounds. Use a workaround.

[PaulRBerg]

The workaround doesn't work with Turbopack

At a minimum, this limitation of Next.js should be documented here:

https://nextjs.org/docs/messages/module-not-found

[samfortunato]

no one cares about software anymore