Improve heft-webpack-basic-tutorial to illustrate .scss support

[octogonz]

• Upgrade to Webpack 5
• Enable webpack.config.js options for .scss support
• Improve webpack.config.js docs
• Add examples of .scss usage

Over time I'm hoping for this project to accumulate a reasonable set of "best practices" for a real world web application. Although it's a "tutorial", I'd like to to aim for this sample to be:

• full featured
• well documented
• realistic

That seems more useful to people than trying to make it simplistic.

These same settings will be integrated into the @rushstack/heft-web-rig setup. Then we'll add a heft-webpack-rig-tutorial, and heft-webpack-basic-tutorial will be the same thing but with all the rig settings inlined.

CC @iclanton @halfnibble

[octogonz]

BTW I noticed that HBO has been using:

• mini-css-extract-plugin - extracts CSS into separate files that can be loaded separately
• optimize-css-assets-webpack-plugin - eliminates duplicates and minifies CSS

Let me know if you have opinions about that approach.

[octogonz]

I also noticed that HBO uses *.module.css to opt-in to modular CSS. Whereas Heft's example projects simply use modular CSS everywhere. This article suggests modular by default, but with *.global.css to opt out of modular CSS.

[halfnibble]

I also noticed that HBO uses *.module.css to opt-in to modular CSS. Whereas Heft's example projects simply use modular CSS everywhere. This article suggests modular by default, but with *.global.css to opt out of modular CSS.

I like the idea in that article. I think we'll need to make this configurable though. Even within our monorepo, we have some projects with different rules for .scss modules. So the current Heft implementation is not ideal. If we agree it should be configurable, then question the becomes, what do we make the default?

[halfnibble]

BTW I noticed that HBO has been using:

• mini-css-extract-plugin - extracts CSS into separate files that can be loaded separately
• optimize-css-assets-webpack-plugin - eliminates duplicates and minifies CSS

Let me know if you have opinions about that approach.

It looks like Webpack's docs recommend using min-css-extract-plugin in production mode to break up assets into more async loads. And they appear to recommend style-loader for local development only.

Interesting. It looks like this was meant to be a piece of code, but instead manifested as a break or paragraph.

[octogonz]

I like the idea in that article. I think we'll need to make this configurable though. Even within our monorepo, we have some projects with different rules for .scss modules. So the current Heft implementation is not ideal. If we agree it should be configurable, then question the becomes, what do we make the default?

From what I've read, CSS modules isn't just a technical feature, it is a policy agenda to discourage global CSS. The reason is to avoid a situation where somebody adds global CSS to a library and it "works fine" for their app, but it breaks someone else's app because of a global naming conflict. This I think motivates a standard where CSS is local-by-default, and then you can opt out by using the filename.global.scss or filename.global.css. Or by specifying the :global selector in your file.

In a monorepo it's pretty important to have consistent conventions, to avoid accidents where someone adds filename.scss to someone else's project, and then is surprised to find that the defaults were different.

CC @bartvandenende-wm

[KevinTCoughlin]

I like the idea in that article. I think we'll need to make this configurable though. Even within our monorepo, we have some projects with different rules for .scss modules. So the current Heft implementation is not ideal. If we agree it should be configurable, then question the becomes, what do we make the default?

From what I've read, CSS modules isn't just a technical feature, it is a policy agenda to discourage global CSS. The reason is to avoid a situation where somebody adds global CSS to a library and it "works fine" for their app, but it breaks someone else's app because of a global naming conflict. This I think motivates a standard where CSS is local-by-default, and then you can opt out by using the filename.global.scss or filename.global.css. Or by specifying the :global selector in your file.

In a monorepo it's pretty important to have consistent conventions, to avoid accidents where someone adds filename.scss to someone else's project, and then is surprised to find that the defaults were different.

CC @bartvandenende-wm

👍 In addition to encapsulation, CSS modules, once supported by browser engines, will provide performance benefits - https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md.

[octogonz]

@KevinTCoughlin also mentioned that autoprefixer can produce unhelpful output if it doesn't have an appropriate browserlist config.

[octogonz]

@Claudiazhaoya said that this is coming eventually https://github.com/microsoft/rushstack/issues/2732

[rootical]

Is there any chance for dart-sass support still? The PR seems to be forgotten

[octogonz]

Is there any chance for dart-sass support still?

@rootical thanks for bringing this up. I assumed that heft-sass-plugin was already using dart-sass, but apparently it is still using node-sass.

The PR seems to be forgotten

This particular PR #3 did get forgotten -- we implemented the ideas in our company's internal rig and never got around to finishing up the public code sample.

However it came up again, because the Rush Stack websites are migrating from Ruby->TypeScript, which has introduced several Webpack projects that need to be maintained as open source. I'm encountering issues with their CSS, so I'm going to see if I can revamp @rushstack/heft-web-rig with an up-to-date and full-featured configuration. I'll see if I can fix the node-sass issue at the same time. And then we can sync all that into heft-webpack-basic-tutorial and finally get this PR merged, too.

Update: https://github.com/microsoft/rushstack/pull/3204