-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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 aliases for paths #274
Comments
Are you defining those aliases in a webpack config? If so, you want the package |
I'm using Meteor which automatically aliases |
My knee-jerk reaction is that the time has come for The two criteria for whether that's actually a good path are
Are those both accurate? |
Meteor does handle the module loading. In Meteor's current implementation, though, I don't think we'll be able to properly build a resolver for Meteor packages.
I would love to have a resolver with full support for Meteor style package imports, but I'm not sure if that's realistic, and the Meteor community is slowly migrating to a full Npm solution. If it's easy to do, having configurable aliases would be really great for the use case of everyone starting new project in Meteor. As far as I can tell Meteor-style packages are essentially deprecated at this point in favor of Npm packages and proper ES6 modules. Having an alias for |
Interesting. Still might warrant a Meteor resolver, as something has to go find the That would be my proposed implementation. I'm up for alternatives, though. FWIW, resolvers are pretty light, in that so far they are just light wrappers around |
do you set I'm thinking the Node resolver could detect that and redefine |
I'm not using Meteor or Webpack, but would like to have aliases because I'm using https://www.npmjs.com/package/pathmodify with Browserify. I'm doing something like this with import FooBar from 'foo/bar/FooBar'; Where settings:
import/alias:
foo: ./src/foo |
Agreed - I don't think this necessarily makes sense as a separate Meteor resolver. Many people use aliases and I think it's a pretty common use case that should be covered, probably by the base node resolver. |
I hear that, I'm just concerned that the alias semantics won't easily generalize across different implementations, so it might be easier maintain explicit resolvers for different alias implementations. I very well may be wrong, though. Maybe could give something to the underlying node-resolve function via pathFilter that would support some common use cases. Might even be able to spec it directly with a JS eslintrc. |
I created a very simple Meteor resolver plugin that looks for the projects root https://www.npmjs.com/package/eslint-import-resolver-meteor This is good enough for my use case. It might still be helpful to have aliases in general but my solution is doing the trick for me. |
Cool, can you add to: https://github.com/benmosher/eslint-plugin-import/wiki/Resolvers Still doesn't solve @psyrendust's case, certainly. Worth trying in an |
I updated the Wiki. |
I have an alias for
/
in my project. I'd like to be able to point the resolver to my alias so that, for example:The text was updated successfully, but these errors were encountered: