-
Notifications
You must be signed in to change notification settings - Fork 54
Fix regexp to not find extensions in the middle of a module name #11
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
Fix regexp to not find extensions in the middle of a module name #11
Conversation
@@ -25,7 +25,7 @@ describe('babel-plugin-css-modules-transform', () => { | |||
} | |||
|
|||
function readExpected(path) { | |||
return readFileSync(resolve(__dirname, path), 'utf8'); | |||
return readFileSync(resolve(__dirname, path), 'utf8').trim(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Used this so that we remove trailing new lines from the expected files. Some (like me) have the editors configured so that the new line is automatically inserted, so figured it'd be good to just ignore that instead of having an exception for these files. If this is something you don't want, I can remove it and remove the new line in the expected file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ran into this too... That said, I'd say it merits a comment to explain why we'd want to trim a file's contents when used as a text fixture.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to do that, if @michalkvasnicak decides it's worth keeping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think this is worth adding? Maybe in another PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@leoasis what do you mean? Adding the regex for query params mentioned by @jvivs (#11 (comment))? Because trimming is already merged so I don't understand this comment. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just meant adding a comment to explain this, as @jvivs suggested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see :) Ok, can you add it in a new PR please? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, can do!
const extensionsPatern = extensions.join('|').replace('.', '\.'); | ||
return new RegExp(`(${extensionsPatern})`, 'i'); | ||
const extensionsPatern = extensions.join('|').replace(/\./g, '\\\.'); | ||
return new RegExp(`(${extensionsPatern})$`, 'i'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're anchoring the match at the end of a stylesheet path (which I think we should), we might want to take into account possible url parameters too... thoughts?
We could use something like this instead:
return new RegExp(`(${extensionsPatern})(\?.*)?$`, 'i');
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am okay with that :) Please create a PR with tests.
Great! thanks @michalkvasnicak |
This PR fixes the Regexp used to filter modules with the supported extensions. Previously it was incorrectly finding modules that contained the extension in the middle of the name. This was both because we were not searching for the last characters in the module (using
$
) and also because it was not escaping the.
caracter properly.Added some more cases to the tests for this fix.
Oh and by the way, thanks for creating this module! Very helpful!