-
Notifications
You must be signed in to change notification settings - Fork 479
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
dots (.) in keys for the config.paths breaks lookup for later non-dotted final file #123
Comments
I expect the problem is mostly in the parseName function. The logic is a bit naive and was really focused on the |
If that is the case, a possible fix is to ensure that for the statement var modName, ext, temp,
strip = false,
dot = name[name.length - 1] === "." ? -1 : name.lastIndexOf("."),
index = name.lastIndexOf("/") > dot ? -1 : dot,
isRelative = name.indexOf('./') === 0 ||
name.indexOf('../') === 0; Seems to fix the first set of cases I got 'text!nodot/target', // pass /srv/tmp/nodot/target
'text!nodot/target.ext', // pass /srv/tmp/nodot/target.ext
'text!nodot/target/file', // pass /srv/tmp/nodot/target/file
'text!nodot/target/file.', // pass /srv/tmp/nodot/target/file. However the remaining cases still don't work, so I guess something else is at play. That said this fixed the apparent regression that was introduced in 2.0.13 |
With version 2.3.5 would this work in nameToUrl (around line 1648) :
instead of
It makes sure that defined paths have precedence. |
Firstly I had this test done in requirejs 2.3.2, requirejs-text 2.0.12, (later I have a test for the latest version (requirejs-text 2.0.15))
The above configuration is set up to effectively append
/srv/tmp/
to the affected paths to illustrate the issue at hand; the test matrix I used:The above is somewhat closer to expected behaviour, where the passing tests have accessed urls with
/srv/tmp/
prepended as configured.With 2.0.15, same configuration:
If I could get an explanation on how or why a
.
character in a directory could just later stop a proper file lookup that do not have a filename extension it would be great. Also trailing dots, now that the latest version managed to consume and ignore that completely.Further to the above, there are a couple more behaviours that I am unsure of (using same configuration as above), they are marked with
????
The first one is especially puzzling since it basically treat
.d/file
as a filename extension tonodot/target
, even thoughfile
is really a file living under thenodot/target.d
directory, which is tracked ambiguously through the configuration.Finally, for completion sake, doing this directly without the plugin (and account for the automatic .js filename extension appending), this is what I saw.
The text was updated successfully, but these errors were encountered: