Allow aliases for paths

[clayne11]

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:

{'/': './imports'}

[jimbolla]

Are you defining those aliases in a webpack config? If so, you want the package eslint-import-resolver-webpack

[clayne11]

I'm using Meteor which automatically aliases / to the root of the project.

[benmosher]

My knee-jerk reaction is that the time has come for eslint-import-resolver-meteor.

The two criteria for whether that's actually a good path are

• Meteor is doing all of your module loading
• there is some pre-existing config file where you've configured Meteor with this and other implicit or explicit aliases

Are those both accurate?

[clayne11]

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.

1. From my understanding, at build time Meteor transpiles "Meteor-style" packages into Npm packages and symlinks them into the node_modules folder. Unfortunately, these transpiled Npm packages only exist within the Meteor build tool as far as I can tell. I haven't been able to figure out where they live on the file-system and I don't think they exist when Meteor is not running which is a bit of an issue for static-analysis.

2. There is no configuration file for the alias. The root of the project (where the .meteor folder is) is automatically set to / by the Meteor build tool. It's implicit.

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 / to the app root would cover most Meteor use-cases.

[benmosher]

Interesting. Still might warrant a Meteor resolver, as something has to go find the .meteor location, unless you want / to alias relative to the CWD of the linter (more fragile).

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 node-resolve.

[benmosher]

do you set env: { meteor: true } in your ESLint config?

I'm thinking the Node resolver could detect that and redefine / as the cwd or package.json location or something.

[psyrendust]

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 pathmodify:

import FooBar from 'foo/bar/FooBar';

Where foo is aliased to ./src/foo. So it would be great to have a config option like:

settings:
    import/alias:
      foo: ./src/foo

[clayne11]

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.

[benmosher]

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.

[clayne11]

I created a very simple Meteor resolver plugin that looks for the projects root package.json file and uses that dir as the root for / paths.

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.

[benmosher]

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 .eslintrc.js and could make a shared config as an example.

[clayne11]

I updated the Wiki.