extensionAlias is not applied to module exports
#355
Comments
|
Hello, sorry for delay, currently it is expected, because But this case is intresting (especially since module request can only be done for Node.js), to be honest I don't have strong opinion here, on the one hand, violation of the specification for this would be a completely wrong decision, but on the other side I see your problem and what you are trying to solve (monorepo and typescript). Based on the logic of modularity and forget about mono-repositories, that is, each package is in its own repository and requires publication (i.e. Also If we allow to do it, some developers can start to rely on this and create a situation when package can't be used without webpack, that is really bad. So I think we're doing the right thing here. I see these solution (and consider them valid as for any bundler as for Node.js itself)
So you can use
|
|
I see what you mean, but I don’t consider this to be a violation of the spec, but parity with the rest of the ecosytem. As can be seen in the output I posted, Webpack already tries to apply the extensions defined in TypeScript’s A very similar issue has been acknowledged in privatenumber/tsx#59. I really appreciate you’re thinking along, but this workaround won’t always work: {
"type": "module",
"exports": {
".": "./index.js",
"./ts": "./index.ts"
}
}Let’s say we have package |
|
I think the problem is still unresolved (in esbuild and for us too) because it creates a situation where users start writing: Because they will expect mapping |
|
hm, Intresting, if you have: and use So you need: And I think you see the problem here. Also Looking at code and the Node.js logic (and not only), I still think you should use |
|
I fully agree with @alexander-akait idea => btw this seems wrong to me: we should not apply extensions.. |
|
For anyone who's also running into this issue, I've fixed this using alternatives as described in the webpacks docs(https://webpack.js.org/guides/package-exports/#alternatives): "exports": {
".": ["./src/index.js", "./src/index.ts"],
"./*": ["./src/*/index.js", "./src/*.js", "./src/*/index.ts", "./src/*.ts"]
},I couldn't find if this is according to the esm spec, but it also works with tsc. |
|
Just encountered this issue with a slightly different setup. I have the following in my "exports": {
".": {
"import": "./dist/index.js"
},
"./runtime.js": {
"import": "./dist/runtime.mjs"
}
},And I'm doing
I'd argue this is definitely wrong, and I have no idea why it's trying to import a typescript file here. |
|
Please provide example of the problem |
|
I made a minimal reproducible one of the issue here. https://github.com/raviqqe/til/tree/main/webpack-exports-extension-alias |
|
You have: And what you expected? Typescript code? Also
If you want to use |
It's just to load JS files. So it doesn't matter.
The Both usage is described in the Node.js's documentation (https://nodejs.org/api/packages.html#subpath-exports). I'm not sure if I'm using it correctly but at least it works with the latest TypeSript's module resolution strategy of @alexander-akait Are you really sure that the usage is wrong? It's literally written in the official documentation. This is also a good read to understand how TypeScript uses |
Where? I mean you can use The You can add this field to https://webpack.js.org/configuration/resolve/#resolveconditionnames and webpack will resolve files from the |
Here.
I think there is a fundamental misunderstanding here about how TypeScript's new module resolution ( |
Is it? I implemented this logic a long time ago TypeStrong/ts-loader#1383 (comment), when typescript realses it, it seems to me that you do not want to listen to me Again - you have a typescript file and want to use |
|
Yes, you do. 😭
No, I'm not talking about supporting the I made my reproducible example TS-free (but with Lisp :) to help your understanding of the bug. Now, the error message looks like this with |
|
Now I see, yeah, it is a bug, I thought that the main idea is to import it, but here it’s the other way around, the idea is not to try to import |
|
The fix is easy, but we need to do deep test with it (I will do soon, hope this week), because ignoring errors can be a problem in some cases when you have |
|
In case someone else arrives here with this issue before it's solved, and need a work-around, I ended up just using a non-aliased file-extension in my "exports": {
".": {
"import": "./dist/index.js"
},
"./runtime.mjs": { // <- mjs is not aliased in my project.
"import": "./dist/runtime.mjs" // <- the extension here does not need to be the same as the line above (even though it is in this case)
}
},[Edit]: |
|
@Alxandr |
|
@alexander-akait it was not a "don't use it cause it's unsafe". It was just a general in my honest opinion, it's a bad idea to use |
github-project-automation
bot
moved this from Priority - High
to Ready for Merge
in webpack 5/6
Let’s say we have a TypeScript mono repo with one package that depends on another. The actual TypeScript configuration is left out, because it’s not needed for this example.
webpack.config.js:package.json:{ "type": "module", "workspaces": [ "packages/*" ], "dependencies": { "webpack": "^5.0.0", "webpack-cli": "^4.0.0" } }foo/packages/package.json:{ "name": "foo", "type": "module", "exports": "./index.js" }foo/packages/index.ts:bar/packages/package.json:{ "name": "bar", "type": "module", "exports": "./index.js" }bar/packages/index.ts:Now if we build using Webpack, it throws the following error:
This shows that
extensionAliasisn’t applied when resolvingimport 'bar'from thefooproject. This can be worked around by removing theexportsfield frompackage.json, but that will cause Node.js to show deprecation warnings if the package would be published and consumed.The text was updated successfully, but these errors were encountered: