Skip to content

Fix bare imports of Sass files with dots.in.filename.scss #259

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

Merged
merged 1 commit into from
Jul 29, 2020

Conversation

vvanpo
Copy link
Contributor

@vvanpo vvanpo commented Jul 29, 2020

As discovered in #256 (comment).

When importing a Sass file that has dots in its filename but without the .scss extension (e.g. @import 'foo.bar';), our resolver would assume .bar was the extension and forego appending .scss, causing require.resolve() to throw an exception.

We need to look for .scss, .sass, and .css extensions, as all of these are possible. Previously, it would automatically assume the extension for the file was the same as the lang attribute set on the <style> block, but Sass has no problems importing .sass from a .scss file or vice-versa, and .css is also very common.

If a Sass file attempted to import something like `~module/foo.bar`, our
custom resolver would expect `.bar` to be the filetype and would forego
appending `.scss` or `.sass`, causing `require.resolve()` to throw an
exception. We can be explicit about the filetype by successively testing
against `.scss`, `.sass` (depending on configured language in the
<style>-bock), and `.css`.

Add `.css` support for bare imports, and `.sass` imports from within
`.scss` or vice-versa.
@vvanpo vvanpo changed the title fix module dots in filename Fix bare imports of Sass files with dots.in.filename.scss Jul 29, 2020
"jest": {
"moduleNameMapper": {
"^~foo/(.*)": "<rootDir>/foo/$1",
// @import '~foo'; -> @import 'path/to/project/foo';
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that GitHub does not like my usage of comments in a JSON block, fair enough, I'll have to change this to a js block.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, comments are not valid json. That's why!

@lmiller1990 lmiller1990 self-requested a review July 29, 2020 09:57
Copy link
Member

@lmiller1990 lmiller1990 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, looks good.

next doesn't even support style loading (at all, yet) so we should look into that sometime. Basically the next branch is the minimal support for Vue 3 SFCs.

This does look good though, thanks! I hope we can port some of these features to next.

@lmiller1990 lmiller1990 merged commit c8c13ae into vuejs:master Jul 29, 2020
@lmiller1990
Copy link
Member

I will release both a new version for 4.x and 5.x this weekend.

@lmiller1990
Copy link
Member

Latest 4.x and 5.x is out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants