Css Nesting Build Script

[TheColaber]

Creates a package.json command npm run transpile-css. When run, it scans all CSS and HTML files and replaces any code that uses nested CSS with plain CSS. This is for compatibility support. Developers will be able to write all CSS using nested CSS if desired and it will still work for the user's devices. Note: This command probably won't be used by developers, it will likely be used when we are sending the extension to web stores.

I made 2 test files, webpages/settings/components/addon-group-header.html and webpages/styles/components/badges.css. Run the package command and the files will get replaced.

I considered using an HTML parser library rather than using regex to find <style> elements but I decided not to since most of the time it alters the HTML especially when it comes to using self-closing tags. We should discuss this further since I'm not really sure of the best route.

Also please keep in mind that I have no idea if this is how I should have done things, but now we have somewhere to start at least :)

@WorldLanguages told me to work on this.

[WorldLanguages]

Personally I find it quite confusing to know when the ampersand is needed and when it's not. Since Chrome 120+ and Firefox 117+ it is needed in fewer places, see: https://developer.chrome.com/blog/css-nesting-relaxed-syntax-update

[TheColaber]

@WorldLanguages Actually I believe you do not need an ampersand in this situation but I put one because I thought it looked better and was more readable. It works with it and without it both in the browser and after being built.

[WorldLanguages]

If this is merged with a package.json file, we should look for other issues/PRs that suggest this file should exist.

[Samq64]

#6272 has its own package.json in the the webpages directory and uses npm instead of yarn.

[TheColaber]

#6272 has its own package.json in the the webpages directory and uses npm instead of yarn.

Shouldn't be an issue then. In fact, it would probably make more sense for their pr to move the package.json to the root, regardless, should be fine.

[WorldLanguages]

I mean, mxmou doesn't need to review the build script, but I'm wondering if it's worth exploring this, as this may simplify writing CSS.
I just checked the original scratchr2.user.css and it does not use nesting, though. I don't know if that's intentional or if the preprocessor didn't support it.

[DNin01]

If this is merged with a package.json file, we should look for other issues/PRs that suggest this file should exist.

I have a related task in the checklist of #6721.

[Hans5958]

I prefer NPM (package-lock.json) over Yarn (yarn.lock), since that's what we used around here (ScratchAddons/contributors, ScratchAddons/website-v2-script, ScratchAddons/l10n-script).

One step closer to build step...

[mxmou]

I just checked the original scratchr2.user.css and it does not use nesting, though. I don't know if that's intentional or if the preprocessor didn't support it.

I don't remember why I didn't use nesting - probably because I was copying selectors from Scratch's styles. Nested selectors would certainly be useful.

[GrahamSH-LLK]

This should be be able to be solved within vite fairly easily (eg. using built in lightningcss support)
I can add it to my PR?

[Hans5958]

This should be be able to be solved within vite fairly easily (eg. using built in lightningcss support) I can add it to my PR?

Would be nice, but then I don't think your PR will be merged in the near future.

I would say we can do this first then replace it later if needed.

[GrahamSH-LLK]

This should be be able to be solved within vite fairly easily (eg. using built in lightningcss support) I can add it to my PR?

Would be nice, but then I don't think your PR will be merged in the near future.

I would say we can do this first then replace it later if needed.

well my PR works quite well and really could be merged 😛

obviously we need to get mv3 done before anything else but i really do think it's ready to merge.