develop vs build styles mismatch due to sass imports

[davidde]

Description

Variables imported from a sass stylesheet are undefined on gatsby build, but work fine on gatsby develop. This results in obscure bugs that only manifest themselves on first page load in production.

I believe this might be the cause of some of these 'mysterious' issues where gatsby build styles differ from gatsby develop, since this probably also happens to each theme or plugin that uses preprocessor imports.

Steps to reproduce

Minimal reproduction based on gatsby-starter-default:
https://github.com/DavidDeprost/gatsby-build--sass-bug

Run gatsby develop, and you'll see the background is violet.
Run gatsby build && gatsby serve, and you'll see it remains white, but turns violet when going to page 2 and back.

Expected result

Sass imported variables should not be undefined on build, so the background is violet from the start, both in development and production.

Actual result

Background remains white on first page load in production.

Environment

  System:
    OS: Linux 4.9 Debian GNU/Linux 9 (stretch) 9 (stretch)
    CPU: (8) x64 Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
    Shell: 5.3.1 - /bin/zsh
  Binaries:
    Node: 10.15.3 - ~/.nvm/versions/node/v10.15.3/bin/node
    npm: 6.12.0 - ~/.nvm/versions/node/v10.15.3/bin/npm
  Languages:
    Python: 3.6.4 - /opt/anaconda3/bin/python
  Browsers:
    Chrome: 77.0.3865.90
    Firefox: 68.2.0esr
  npmPackages:
    gatsby: ^2.17.15 => 2.17.15
    gatsby-image: ^2.2.33 => 2.2.33
    gatsby-plugin-manifest: ^2.2.28 => 2.2.28
    gatsby-plugin-offline: ^2.2.10 => 2.2.10
    gatsby-plugin-react-helmet: ^3.1.15 => 3.1.15
    gatsby-plugin-sass: ^2.1.23 => 2.1.23
    gatsby-plugin-sharp: ^2.3.0 => 2.3.0
    gatsby-source-filesystem: ^2.1.37 => 2.1.37
    gatsby-transformer-sharp: ^2.3.5 => 2.3.5
  npmGlobalPackages:
    gatsby-cli: 2.8.11

[andrea-ligios]

It's important to note that this also happens with Office UI Fabric components, which is huge.

I'm writing a webapp with Gatsby and Office UI Fabric React, which is scss based, and this is exactly what's happening!

I hope someone will fix this, 'cause disabling rehydration is not a solution at all...

[KyleAMathews]

Does this seem like something related to gatsby-plugin-sass? There doesn't seem like there's any prod vs. develop in the plugin unless I'm missing something https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-plugin-sass/src/gatsby-node.js

[davidde]

Good thinking.
Seems indeed due to the sassRule not using the importLoaders when server side rendering.

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[andrea-ligios]

Don't go spooky quiet...

[wardpeet]

Hey,

I have looked at your issue here and what you're talking about looks like ICSS. ICSS is part of the css-modules spec. css-modules is only enabled on files with the .module.scss postfix (eg. x.module.scss). If you want your solution to work, you'll have to rename the layout.scss into layout.module.scss.

I'm marking this issue as answered and closing it for now but please feel free to reopen this and comment if you would like to continue this discussion. We hope we managed to help and thank you for using Gatsby! 💜

[davidde]

Hi @wardpeet

Please reopen this; I can see how this looks like ICSS since the syntax is exactly the same, but sass exports are actually also a sass feature that should work independently of ICSS.

They are specified with the :export keyword, e.g. in layout.scss:

:export {
  violet: violet;
}

Note that in this specific case, using the .module syntax indeed fixes it, but if layout.scss contained any CSS classes or ids, all of those would be broken by using the CSS module syntax.

As I said in a previous comment, this bug seems to be caused by the sassRule in gatsby-plugin-sass, which does not use the importLoaders when server side rendering.

I'll send a PR with a simple fix.

[davidde]

Seems the first PR was on my own repo ;)
I'm really not that used to doing things inside the Github UI ...

[vladar]

but sass exports are actually also a sass feature that should work independently of ICSS

This doesn't seem to be the case. Pure Sass just passes :export into css output as is (example).

It is css-loader who processes it as a part of its ICSS/css-modules support (CSS loader uses icss-utils for this). This only works with webpack (or Sass+PostCSS with css-modules). Doesn't work with pure Sass.

[davidde]

@vladar
Totally didn't know :export was just passed into css. Thanks for showing it with an example.

However, using the module syntax will also break all classes and ids, which would need to be prefixed with the import name. So I guess this also means there is no 'simple fix' for this bug?

[wardpeet]

The bug is that we shouldn't allow this on develop or production rehydration as this is not a css/sass/less feature but a css-modules one.

An option you could do is create a json or js file which holds your variables and use the prependdata option that sass provides.

This should roughly look like this inside your gatsby-config.js file.

const createPrepenDataString = () => {
  const tokens = require('path_to_token_file.js');

  let dataString;
  for (var key in tokens) {
    dataString += `$${key}: '${tokens[key]}';`
  }

  return dataString;
}

module.exports = {
plugins: [
{
  resolve: `gatsby-plugin-sass`,
  options: {
    prependdata: createPrepenDataString()
  }
},
]
}

[davidde]

OK, that makes sense. In this case, it would definitely make more sense if none of the imports worked, neither in dev nor prod. But I believe this would also complicate things for a lot of people, so it might be wise to get an idea first of how many people depend on this behavior.

Thanks for the suggestion.