Streamlining production of tailwindcss bundled css, introducing multiple entryfiles for content-ui foldesr

Make tailwindcss centralized css production settings, without creating postcss config in every package.json Added multiple entryfiles just for content-ui

Priority*

[ ] High: This PR needs to be merged first for other tasks.
[x] Middle: This PR should be merged quickly to prevent conflicts due to common changes. (default)
[ ] Low: This PR does not affect other tasks, so it can be merged later.

Purpose of the PR*

Streamlining css production for shadowdom, which included minification and treeshaking to be used for shadowdom Added multiple entryfiles just for content-ui

Changes*

1) Tailwindcss bundle production is a mess, i created a plugin to be shared accross all pages folder, without the need of redundant @tailwind base ... etc, to be pasted all over the code, the plugin itself contains the postcss config, and thereby internalizing the css production for shadowdom. And hence the command https://github.com/Jonghakseo/chrome-extension-boilerplate-react-vite/blob/a7d51c3266803703e211223e49de675d119fdfa6/pages/content-ui/package.json#L15C1-L16C1 can be removed, and this also fixes hmr crashes upon live editing of tailwindcss classess

2) Multi entry files for content-ui folder, as a normal dev will have multiple subdomains to inject across, its smarter to have multiple entry files injected for different subdomains, I've made the script to autogenerate folders and files inside content-ui, but u have to pay attention as well to make changes in manifest.js

How to check the feature

Everything works even without the postcss config in package.json, and every pages now have its own generated global-out.css

just fork my repo and install as usual, you'll see all the tailwindcss still works perfectly

https://discord.com/channels/1263404974830915637/1264514968288759889/1285558712941023345 as you see above hmr doesn't crash

All the css is still working but with leaner size

There are three changes to this PR

centralization of tailwindcss bundling

add multiple entry points for content-ui

update package (?)

First of all, the centralization of the CSS bundling process into the build process seems like a good idea. Basically I support your idea, but I'm concerned that we need to make sure there are no side effects or unexpected issues, that it's not a common implementation and users may struggle when adding the plugin from existing settings(by some tutorials, guide...), and that it's difficult to set the settings separately on each page.

Second, I'm skeptical that adding an entry point for content-ui is a necessary task. Users can achieve the same thing by copy/pasting the pages they want, such as content, content-ui, and registering them in the manifest if they want. My understanding is that this is a convenience feature, is that correct? Please let me know if I'm missing something.

based on ur first question, since the original code was already opinionated on tailwindcss i just help u to internalize the bundle process which is the exact same as running the build:tailwindcss script, your approach doesnt provide hmr and mine does. we can ofc work on different ui package which people ccan just install whtever ui library they want. but the step of bundling should be the same

Jonghakseo / chrome-extension-boilerplate-react-vite