SASS precision & CSS Modules configuration

[mingaldrichgan]

This pull request replaces #1900 — please refer to my correspondence with @KyleAMathews there for more context.

1. SASS precision option

SASS defaults to 5 digits of precision, which is too low for Bootstrap. This pull request adds a precision option to gatsby-plugin-sass and gatsby-plugin-postcss-sass.

2. CSS Modules configuration

In my original pull request, I made the CSS Modules localIdentName configurable for gatsby-plugin-sass. My use case for that was to include the [path] (for development, as it is not uncommon to have CSS files with the same name in different folders). Kyle suggested that we include [path] by default, in which case I don't think there is much value in making this configurable.

In this pull request, I refactored out the CSS Modules configuration from webpack.config.js and the various plugins into gatsby/src/utils/css-modules-config.js. Although the localIdentName is not currently configurable, the getLocalIdentName() function now acts as a single source of truth and can be easily changed/extended in the future.

3. gatsby-plugin-react-css-modules

This is a new package for integrating babel-plugin-react-css-modules into a Gatsby project. This is certainly not required to use CSS Modules, but it is an option.

4. Miscellaneous

While working on this, I noticed that gatsby-plugin-sass did not configure the SASS loader for the develop-html stage, whereas gatsby-plugin-postcss-sass did. This is also included in this pull request.

[gatsbybot]

Deploy preview ready!

Built with commit d729eb6

https://deploy-preview-1934--gatsbygram.netlify.com

[KyleAMathews]

Deploy preview failed.

Built with commit d85f726

https://app.netlify.com/sites/using-glamor/deploys/59a4a8eacf321c44fec01164

[KyleAMathews]

This looks great! Some nice refactoring & new functionality/tests ❤️

[KyleAMathews]

But hmmm some of the tests are failing atm because the require("gatsby/dist…") import is failing. I think you need to mock it during the tests?

[mingaldrichgan]

Hmmm they passed locally (works on my machine!) but maybe that's because I had yarn run watch running? I'll take a look.

[jquense]

see webpack-contrib/css-loader#406 its actually more efficient to use the name with the path and name and local with a sort hash

[mingaldrichgan]

Good to know! Would you recommend sticking with [path]---[name]---[local]---[hash:base64:5] for both dev and prod then?

[jquense]

yup!

[jquense]

this is not a great pattern i don't think :/ it makes it really hard to understand what bits of the gatsby package are public and which aren't. Not to mention it ties the plugin to specific versions of gatsby that isn't documented anywhere

[KyleAMathews]

Hmm yeah. We don't have good patterns yet for exposing public helper functions like this…

[mingaldrichgan]

OK. Would adding gatsby as a devDependency of these plugins be a bad idea? I guess so. Any suggestions for how to share the CSS Modules configuration between the core webpack.config.js and the different plugins? I thought about using an environment variable but didn't think that would be a good idea.

[mingaldrichgan]

Elaborating on this idea—I initially thought that storing the localIdentName config in an environment variable would not only make it reusable between plugins but also easily configurable by the user. However, the documented method of setting environment variables via .env.* files would not work because this environment variable would have to be available at the time webpack.config.js is evaluated, i.e. before DefinePlugin is loaded.

[jquense]

I think v2 handles this neatly for the webpack case, we pass in essentially this helper to the plugin, vs the plugin requesting it.

Generally I think it makes the most sense to do either:

• pass what is needed to gatsby plugins via the plugin api
• extract the helper into a separately versioned package (MONOREEEEEEEPOOOOOO)

[KyleAMathews]

MONOREEEEEEEPOOOOOO

LOL! And yeah, that seems like the nicest solution for now — super easy to make a new package (npm run plop). Add gatsby-1 to the package name so it's super obvious this is only needed for Gatsby 1 as it sounds like we can do things differently in v2.

[KyleAMathews]

Thanks! Making new release.

[jlengstorf]

Hiya @mingaldrichgan! 👋

This is definitely late, but on behalf of the entire Gatsby community, I wanted to say thank you for being here.

Gatsby is built by awesome people like you. Let us say “thanks” in two ways:

1. We’d like to send you some Gatsby swag. As a token of our appreciation, you can go to the Gatsby Swag Store and log in with your GitHub account to get a coupon code good for one free piece of swag. (We’ve got t-shirts and hats, plus some socks that are really razzing our berries right now.)
2. If you’re not already part of it, we just invited you to join the Gatsby organization on GitHub. This will add you to our team of maintainers. You’ll receive an email shortly asking you to confirm. By joining the team, you’ll be able to label issues, review pull requests, and merge approved pull requests.

If you have questions, please don’t hesitate to reach out to us: tweet at @gatsbyjs and we’ll come a-runnin’.

Thanks again! 💪💜