Vue-jest: SCSS @import to Webpack alias fails in 2.2.0

Created on 18 Mar 2018  路  11Comments  路  Source: vuejs/vue-jest

There seems to be a critical bug in 2.2.0 with the introduction of SCSS support. When trying to import a file with:

@import '~@design';

I see the repeated error:

File to import not found or unreadable: src/components/~@design.
Parent style sheet: stdin

  at Object.module.exports.renderSync (node_modules/node-sass/lib/index.js:439:16)
  at module.exports (node_modules/vue-jest/lib/compilers/scss-compiler.js:28:15)
  at processStyleByLang (node_modules/vue-jest/lib/process-style.js:6:82)
  at processStyle (node_modules/vue-jest/lib/process-style.js:15:17)
  at parts.styles.map.ast (node_modules/vue-jest/lib/process.js:98:11)
    at Array.map (<anonymous>)
  at Object.module.exports [as process] (node_modules/vue-jest/lib/process.js:93:35)

This causes every test to fail, even ones that don't have anything to do with Vue or SCSS - and even when those tests are run in isolation, oddly. Unfortunately, matching neither @design nor ~@design in moduleNameMapper has seemed to have any effect.

As a side note, seeing as there still seem to be quite a few other issues with CSS support in general, I wonder if trying to compile styles should be an opt-in experimental feature for now.

Most helpful comment

To turn off CSS compilation in v2.3.0:

"globals": {
  "vue-jest": {
    "experimentalCSSCompile": false
  }
}

All 11 comments

Thanks for the bug report Chris. This is fixed in 2.2.1

I agree, we should add styles as an experimental feature. We can use Jest globals to do this. Users would need to add this to their Jest config:

{
"globals": {
  "vue-jest": {
    "experimentalStyles": true
  }
}

I'll add this to the 3.x release, and keep it hidden behind a flag until it has become stable.

Thanks! I have confirmed that in 2.2.1, the parsing errors no longer cause all tests to fail, so this issue can probably be closed. 馃檪 However, I noticed that mocking $style no longer seems to work, such as in this test. So for now, I think I still have to lock to 2.1.x.

Before 3.x is released, what would you think about having style compilation turned on by default, but allowing users to set:

"globals": {
  "vue-jest": {
    "experimentalStyles": false
  }
}

to turn them off? That way, existing users whose CSS is causing issues can still take advantage of other, non-CSS fixes and improvements in vue-jest.

I'm also having a similar problem with stylus, which could be solved by opting out of compiling styles. The stylus-loader package supports Webpack aliasing, which breaks all tests for components where someone requires another style using an alias.

@require '~someAlias/blah/blah/myStyle.styl

I can confirm @garytryan.
In my usecase I'm not able to integrate with an external package:

`stylus:184:9
180|
181|
182|
183|
184| @import '~nm-base/src/_variables.styl'
----------------^
185| /@import '../../../../../node_modules/nm-base/src/_variables.styl'/
186| /@import '~nm-base/src/_mixins.styl'/
187|

failed to locate @import file ~nm-base/src/_variables.styl`

@konstantinsteinmiller for now you can use version 1.4.0, which doesn't compile stylus.

@eddyerburgh it looks to me like this doesn't work because stylus doesn't support aliasing. This is a feature supported by stylus-loader.

To turn off CSS compilation in v2.3.0:

"globals": {
  "vue-jest": {
    "experimentalCSSCompile": false
  }
}

Thanks @eddyerburgh! 馃檪 This is working perfectly. I'll leave this up to you about whether to keep this open. I guess it's more of a general module mappings not being available in CSS problem than anything specific to SCSS.

Thanks @eddyerburgh!

@chrisvfritz After merging https://github.com/vuejs/vue-jest/pull/82 matching via moduleNameMapper will work for SCSS. Maybe we can even make that work in stylus since the module responsible for resolving the aliases is already separated into a helper.

@chrisvfritz #82 is merged and released! Please try SCSS/Sass compilation and let me know if you encounter any problems. :-)

@eddyerburgh Should we maybe close this? =)

Was this page helpful?
0 / 5 - 0 ratings