_This issue was transferred from rollup-plugin-alias, which lacked an issue template_
Reviewing the various PRs for rollup/rollup-plugin-alias#11, I was struck by how much extra work is created for the sake of allowing users to do this...
alias({
foo: 'bar'
})
...when they mean this:
alias({
foo: 'bar.js'
})
In my view there's no good reason to support that. Extension-less imports is a bad habit encouraged by Node's ill-conceived module resolution algorithm. Being explicit and obvious (rather than relying on scattered bits of magic) makes life easier for whichever developer inherits a project, and it would allow us to remove a lot of moving parts (including the resolve option).
Breaking, obviously, so would have to be a version 2. Thoughts?
@Rich-Harris I'd love to see this integrated, even if it requires a major bump. Otherwise, an alternative or workaround would be appreciated!
This is preventing me from using this in a TypeScript build setup because it is automatically adding .js when I just want to put .ts
This also break my import './some-my-style.css';.
@Rich-Harris is this one still relevant?
I just ran into this problem too, when I want to alias a JSON file and then load it with rollup-plugin-json, it fails because this configuration:
{find: 'aliased-json', replacement: './test.json'},
makes it look for test.json.js.
So I have to create a dummy JS test.js next to test.json that just imports and exports test.json, and then alias to that rather than my JSON file.
If a non-breaking change was desired, an option could be added to disable the automatic file extension.
EDIT: Sorry, I just realized what the resolve option does. Still seems like it'd be better to change the default behavior :)
webpack has a similar thing that allows us to alias directories so we can even alias to asset files that might be images.
Currently my config is
alias({
'@assets': __dirname + '/src/assets'
}),
And i'm doing
import png from "@assets/icon.png";
but this adds .js to the end of the file.. which is not ideal. it seems alias shouldnt be bound to a file type assumption.
Another approach could be to use the this.resolve context function to resolve this. If someone were to use rollup-plugin-node-resolve, they get the resolution algorithm they know and love, otherwise just what is built-in. @Acionyx has been contacting me because he is working on a fork to do just that but I did not yet find time to have a look.
@lukastaegert could you give a small example of using this.resolve?
Cheers.
Here is a real-world example, though it is probably not a simple one: https://github.com/rollup/rollup-plugin-commonjs/blob/535e8117607731e1e8688be84c3aeb6e5c3b6fa5/src/resolve-id.js#L54
Here it is taking an import of the form commonjs-proxy:./some-imports.js, removes the prefix and uses this.resolve to find out what path the import of ./some-import.js resolves to.
this.resolve() and should alleviate this issue. If it still pops up with the new version, please respond and we'll reopen.
Most helpful comment
This is preventing me from using this in a TypeScript build setup because it is automatically adding
.jswhen I just want to put.ts