-
Notifications
You must be signed in to change notification settings - Fork 23
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
Improve heft-webpack-basic-tutorial to illustrate .scss support #3
base: main
Are you sure you want to change the base?
Conversation
BTW I noticed that HBO has been using:
Let me know if you have opinions about that approach. |
I also noticed that HBO uses |
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? |
It looks like Webpack's docs recommend using Interesting. It looks like this was meant to be a piece of code, but instead manifested as a break or paragraph. |
@@ -3,7 +3,7 @@ | |||
|
|||
"compilerOptions": { | |||
"outDir": "lib", | |||
"rootDir": "src", | |||
"rootDirs": ["src/", "temp/sass-ts/"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe @iclanton will remember for certain, but I vaguely remember there being something counterintuitive about the "rootDirs" field that required us to keep both "rootDir" and "rootDirs". I think "rootDir" is used for calculating the root path and if you don't have a TS file in your "src" folder, then you might lose your folder structure without it being also specified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@halfnibble good catch!
You are right, despite the name, rootDir
and rootDirs
are very different settings:
rootDir
explicitly specifies the folder that will be used as the basis forlib
output; otherwise it will be inferred from the common parent of thefiles
,include
, etcrootDirs
specifies directories with additional typings that will be overlayed on the mainsrc
directory tree, under the assumption that those.js
files will all get copied into the same output folder.
Specifying rootDirs
does not influence the rootDir
.
As an experiment, with "rootDir": "src"
deleted in this branch, if I move all my files to be src/x/*.ts
they wrongly get compiled to lib/*.ts
instead of lib/x/*.ts
.
The naming of these settings is very misleading.
…he css-loader config
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 In a monorepo it's pretty important to have consistent conventions, to avoid accidents where someone adds |
👍 In addition to encapsulation, CSS modules, once supported by browser engines, will provide performance benefits - |
@KevinTCoughlin also mentioned that autoprefixer can produce unhelpful output if it doesn't have an appropriate browserlist config. |
@Claudiazhaoya said that this is coming eventually microsoft/rushstack#2732 |
{ | ||
// Compiles SASS syntax into CSS | ||
// https://www.npmjs.com/package/sass-loader | ||
loader: 'sass-loader', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bartvandenende-wm pointed out that this recipe will apply SASS transformations to .css files, which we don't want
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're thinking to change the rig to work like this:
.css
: NO sass, NO autoprefixer, NO modules.scss
: sass, autoprefixer, modules.global.scss
: sass, autoprefixer, NO modules
...and if someone wants CSS with modules, they can simply use the .sass
file extension, since SASS is basically a superset of CSS.
There's a small performance penalty for applying SASS to a plain CSS file, but @halfnibble pointed out that the extra syntax validation probably justifies that cost.
Is there any chance for dart-sass support still? The PR seems to be forgotten |
@rootical thanks for bringing this up. I assumed that
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 Update: microsoft/rushstack#3204 |
…to octogonz/scss-improvements # Conflicts: # common/config/rush/pnpm-lock.yaml # common/config/rush/repo-state.json # heft/heft-node-basic-tutorial/package.json # heft/heft-node-jest-tutorial/package.json # heft/heft-node-rig-tutorial/package.json # heft/heft-webpack-basic-tutorial/package.json # other/packlets-tutorial/package.json
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:
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 aheft-webpack-rig-tutorial
, andheft-webpack-basic-tutorial
will be the same thing but with all the rig settings inlined.CC @iclanton @halfnibble