-
Notifications
You must be signed in to change notification settings - Fork 5
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
Support wildcard imports #6
Comments
Can you give me an example, in the esm code, of wildcard imports that gives an error with the current solution? |
My resolve code looks like this
In my esm code I then have
esm-module-alias then fails to substitute the alias because I suppose the code works if you have
But from a semantic point of view I don't think that's particularly clean, since I wouldn't want
|
The purpose of this lib was having a way to basically keep the same code of a project using module-alias and commonjs but passing to esm. Since this seems to me to be the behaviour of module-alias, I will not change it. Maybe later I will think about a perfect behaviour for the path-matching-alias part. What I will probably do now instead is allowing users to customize the matching behaviour, so that you can change the function as you wish. I'll write a comment here when the feature is in production. Thanks for the issue, |
Fixed by PR #7 |
Currently you need to specify the alias for each module, which can be quite cumbersome if you have multiple modules. It would be great if you could support wildcard imports. Something as easy as replacing
with this works
The text was updated successfully, but these errors were encountered: