search

johvin / eslint-import-resolver-alias

a simple Node behavior import resolution plugin for eslint-plugin-import, supporting module alias
MIT License
181 stars 10 forks source link

Characters in aliases interpreted as regex #15

Open slifty opened 4 years ago

slifty commented 4 years ago

Thank you for the project!

We're using module-alias in our project to prevent import hell. According to this issue they are recommending a $ prefix to aliases in order to avoid the @ that is being used as a namespace among npm packages.

It looks like your plugin will interpret $ as regex, which means if I had an alias for $src defined, I would need to write in my eslint alias settings:

'\\$src', './src'

I'm not sure the ideal solution from a project perspective, but it would be great to be able to use $ (or other regex characters) in my aliases.

Note: in our case we are addressing this by changing $src to %src but ideally we wouldn't have to.

aryzing commented 3 years ago

That's how regexes work, the $ has special meaning, You'll just have to escape the character in your regexes. Not sure modifying the special char you're using you're using to avoid "import hell" is an ideal solution from a project perspective, given you only configure this tool once, yet write code with your chosen prefix every day.

slifty commented 3 years ago

Thanks @aryzing -- It's been a while, but I believe the root of my issue as posted was that it was unexpected to me that the alias name was being treated as a regular expression at all. It isn't currently documented that this value is being treated as a regular expression, and it was surprising to me as an end user to have my alias be interpreted as such. Hence the issue title.

I appreciate that under the hood the matching uses my configuration value as a regular expression. That should either be:

  1. an implementation decision that is invisible to the end user (i.e. I could use regex characters in my aliases and the tool would escape them for me), or
  2. a documented feature that is part of the communicated API.

It seems to be a moot point of course, as this project doesn't appear to be active any longer (and in my case we ended up NOT using aliases at all, opting for just being explicit in our imports).

All that said you're right that having a slightly ugly config in one place makes way more sense than using % over $ -- it's a very good point!