Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency with TypeScript in Module Resolution with Fully-Specified ESM Imports #904

Open
karlhorky opened this issue Apr 28, 2021 · 3 comments

Comments

@karlhorky
Copy link

karlhorky commented Apr 28, 2021

I'm submitting a bug report

Webpack Version:
5.36.0

Babel Core Version:
7.13.16

Babel Loader Version:
8.2.2

Please tell us about your environment:
Windows 10

Current behavior:

Fully-specified ES Module Imports (with the .js extension) do not resolve to the correct, matching .ts or .tsx files (as is the behavior of TypeScript and tsx, as per the TypeScript team here: microsoft/TypeScript#41887 (comment) )

See more details at the issue in the webpack repo: webpack/webpack#13252

Expected/desired behavior:

babel-loader resolves modules the same as TypeScript and tsx do.

  • If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem along with a gist/jsbin of your webpack configuration.

https://github.com/Josehower/webpack-babel-test

  • What is the expected behavior?

babel-loader resolves modules the same as TypeScript and tsx do.

  • What is the motivation / use case for changing the behavior?

It's unexpected that what works in TypeScript + tsx does not work with webpack and babel-loader

@nicolo-ribaudo
Copy link
Member

babel-loader doesn't do any module resolution: it's just about compiling syntax.

You could use a Babel plugin to rewrite import paths (for example, https://www.npmjs.com/package/babel-plugin-module-rewrite), but it really should be done by configuring webpack to use the resolution strategy you want.

@karlhorky
Copy link
Author

karlhorky commented Apr 28, 2021

Yeah, that was my first impression as well - first of all, we started the investigation on the webpack end.

But in the end, users will configure babel-loader and expect that any valid ESM imports that work with TypeScript + tsc will also work there.

As Alexander says below, webpack is currently working correctly, so this becomes a concern of the loaders, such as ts-loader, which he will work on:

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

webpack/webpack#13252 (comment)

More details from Alexander:

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).

@karlhorky
Copy link
Author

Ah Sokra has now said it will probably be in core:

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

webpack/webpack#13252 (comment)

So I guess once this resolver plugin exists, if it won't be enabled automatically (which would be ideal), loaders who consume TS should verify that this resolver plugin is enabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants