feat(*): add css scoping to each block

[fulopdaniel]

Created a PostCSS Plugin that prepends every css rule in the generated style.css with an extra selector, essentially scoping the whole css file to the specific block.

.foo .bar { ... }

becomes

.text-block .foo .bar { ... }

Previously we relied on Tailwind's important scoping approach, but that does not scope css rules that were imported to the package (e.g. @frontify/guideline-blocks-settings/dist/style.css)

To test:

1. run pnpm run deploy --dryRun inside any package
2. check the style.css inside the /dist folder of the package
3. all rules should be scoped

[fulopdaniel]

https://app.clickup.com/t/8693f384y

[hochreutenerl]

Nice direction where this is going. @fulopdaniel
Would it even be possible to scope with the appId (read it from the manifest), so we can have a solution that also works for external blocks?

[ragi96]

And I noticed that the css build now is smaller and I don't get why thats the case as it should be bigger, are we missing something?

[ragi96]

Sorry, fat finger approved it.

[fulopdaniel]

@hochreutenerl We could read the manifest.json, but that does not automatically solve the issue for external blocks. They will need to configure their postcss.config.js themselves either way, and then also add that class to their block.

@ragi96 I will look into the point with the css size. One potential reason why the bundle could be smaller is that I removed the tailwind important part, so that is no longer part of the bundle.

Update: The CSS is has the same amount of lines with and without the plugin. The tailwind 'important' approach duplicated some rules, that's why the previous bundle was bigger.

[ragi96]

LGTM

[hochreutenerl]

@fulopdaniel I think we can also adjust our templates - not all of them use postcss though - and add a matching class to wrapping div.
It's fine for me to do it as a later stage.

[ragi96]

@hochreutenerl then we probably should release the plugin properly so we don't have to copy paste the code