-
Notifications
You must be signed in to change notification settings - Fork 26
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
Allowing paths after alias causes error when requiring sub-modules #17
Comments
Hmm... You are not the only person with this issue (see #14). I'm not sure what the best way to fix this is, though. Maybe something like:
This strikes me as "not quite right", though. |
Interestingly, that's almost the exact solution I tried out on my local fork. I agree that it just doesn't seem 'right' enough. |
So, what you can do right now is set your aliasify config up as:
And this will have the desired effect. This works because when we try to transform "react/addons" we'll first try to find a "react/addons" key in the aliasify config, and only if we don't find one will we try to turn "react/addons" into "react" and then find "react/addons/addons". This also doesn't seem like an ideal way to do this, since it relies on behavior which is, if I'm honest, an accident. :P |
I'm trying to create an alias for a file in a module, but it isn't working: #48 |
First, my specific example that led to finding this issue:
I have source modules that may require either the core React module or the React module with addons, such as:
I am attempting to use aliasify to map any requires of
react
toreact/addons
. However, I want to leave requires forreact/addons
untouched. When I include the following in mypackage.json
,require('react/addons')
becomesrequire('react/addons/addons')
:At first, I thought this might be a bug with
aliasify
being too lenient, but it looks like it's expected functionality, considering this test to ensure paths after aliases are maintained.I attempted to work around this by using quote marks in my package.json, like so:
Hoping that I would be able to do an 'exact' match against only requires for
'react'
, but to no avail.This pattern of modules exposing differing or extended functionality via sub-modules (e.g. Less 2.0.0 just introduced
less/browser
as a valid require target) seems to not be that uncommon, so I was curious as to whether you feel there's a way to improvealiasify
to be smarter about aliasing modules names with this pattern.Thanks.
The text was updated successfully, but these errors were encountered: