-
-
Notifications
You must be signed in to change notification settings - Fork 433
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
Allow imports with .js extension #465
Comments
Just include
|
I defined the extensions, and it's not working. My config :
|
It's a very simple test project :
|
You need to register a loader for your js; something like this: {
test: /\.js$/,
exclude: /node_modules/,
use: [
{
loader: 'babel-loader',
options: babelOptions
}
]
} |
Why should I use another transpiler/loader ? My code is in TypeScript and TypeScript itself know how to resolve this : A ts-loader should follow TS features. |
Maybe it wasn't clear, but |
If I was you then I would do this:
i.e. go extensionless. That's pretty much how webpack is setup to work, TypeScript is happy with that and ts-loader works with that. |
Yes, but it's not ES6 compatible. So if I do (after classic dev transpilation with
Then the import of |
If you're using webpack, you're using webpack. I think what you're suggesting is not related to webpack + TypeScript usage. I'm not sure this is the right forum for you. What you're asking for is not webpack related as far as I can tell. |
So you suggest I bundle my app with webpack each time I do a little modification during development ? I'm sure you don't do this either, as it can take a few minutes with real apps. My code need to be the same for dev and prod. So now, I have to choose between being able to use webpack for prod (if I use extension-less imports), or being able to load my scripts in development with the new native loader But that's not even the point. It's a TypeScript feature since 2.0. A ts-loader should follow TypeScript features. |
Yup - in watch mode that's exactly what I do. After the initial compilation it takes a matter of seconds to recompile for the app I'm working on at present.
That seems very strange indeed. Typically you run in debug with full sourcemaps and no minification, then in production you run without sourcemaps and with minification.
If you mean
If this is your huckleberry then why do you want to use webpack at all? |
This issue has nothing to do with the |
See https://webpack.js.org/configuration/resolve/#resolve-extensions for more information on this. In short, you need to add "*" to your |
Not working either. |
I missed the part about TS automagically changing the extension in it's lookup from |
Can't ts-loader let typescript do this ? |
You're conflating two separate systems. TypeScript is one system that understands modules and implements its own module resolution algorithm and rules. webpack is a completely different system with its own module resolution algorithm and rules. ts-loader sits in-between the two and effectively passes source back back and forth between them. Just because TypeScript knows that when you say ts-loader has quite a bit of control over the TypeScript system and is able to change the TypeScript module resolution algorithm to roughly match that of webpacks. The inverse is not necessarily true. |
Also, in case it's not clear, I believe the error |
Hello, I'm using |
Here is a really valid use case: A lib author wants to write ESM-compatible TS code and output both ESM JS and a UMD bundle for legacy reasons or In TypeScript, they use The lib author publishes the ESM files, and those work great for people that use Node ESM, Webpack 5+, or native Browser ESM. The author also wants to release a single bundle for users that prefer However, the lib author will not be able to build the desired bundle for the It seems it is A current workaround is to first build output ESM files with TypeScript's |
Just came across this issue when looking up a problem of ts-loader not picking up plain javascript files, even though the module.exports = (env) => ({
resolve: {
extensions: [".tsx", ".ts", ".js"]
},
module: {
rules: [
{
test: /\.(js|tsx?)$/,
use: "ts-loader",
exclude: /node_modules/
}
]
},
// other config...
}); |
That doesn't work. same problems. Your "other config..." must be doing something important..... My solution is to just have webpack work on the normal typescript output. ts-loader is never going to fix this bug as it was instant-closed the day it was filed, 4 years ago. |
Closed? Many TypeScript projects targeting ESM will face this issue. FWIW, popular projects which have switched to ESM+TS are already using this syntax. eg: https://github.com/sindresorhus/got/blob/main/source/core/index.ts |
This issue by itself render For other finding this (unfortunately) closed issues, the project https://github.com/softwareventures/resolve-typescript-plugin provides the extra step required to make this work. |
This is a great shout. If someone would like to submit a docs PR to suggest that people with this need use @djcsdy plugin, we'd happily take it. |
It's unfortunate this issue is being ignored by this community-- ease of use is important to developers, especially when updating projects, and responses like the ones above are unfortunate this isn't being resolved in this loader. The community here should re-consider this ticket, it's absolutely valid and this is the correct forum. |
@joelachance you're part of this community. If you'd like to work on this it would be very welcome ❤️ |
@joelachance Webpack itself provides a solution to this problem now. module.exports = {
//...
resolve: {
extensionAlias: {
'.js': ['.ts', '.js'],
'.mjs': ['.mts', '.mjs'],
},
},
}; See: https://webpack.js.org/configuration/resolve/#resolveextensionalias I also recommend: module.exports = {
//...
resolve: {
enforceExtension: true,
},
}; to enforce use of file extensions for full compatibility with ES Modules. If for some reason you can't use a recent version of Webpack that includes these options, use https://github.com/softwareventures/resolve-typescript-plugin Full disclosure: I am the author of the above plugin. |
Thank you for the quick responses! @djcsdy @johnnyreilly |
Since TS 2.0, it's possible to :
import { Something } from './something.js'
;But using this possibility with ts-loader results in error :
Module not found: Error: Can't resolve './something.js'
It's important to be compatible with ES6 modules, which require the
.js
extension, as<script type="module"></script>
is now in test in all browsers, and as for now TS doesn't provide an option to add the.js
extension in transpiled files (see microsoft/TypeScript#13422).It's possible in rollup/rollup-plugin-typescript so I assume it's possible with ts-loader too.
The text was updated successfully, but these errors were encountered: