stencil-cli
stencil-cli copied to clipboard
bigcommerce
Feature Request: Remove unused CSS from compiled theme stylesheet
It would be great if stencil-cli could remove used css from production files to help control the size of the files using something like Purgecss.
Every BigCommerce theme would benefit from this feature and I would be happy to help and submit a PR. Here are my thoughts on how this feature could look.
Add a new --optimize flag to stencil start to run a local server with unused css removed. This can be used to test locally and makes sure everything works with your site before creating a new release. Any unused css will be removed when running bundle, release and push without having to use the --optimize flag.
What are your thoughts on this @junedkazi?
@tomdiggle this is a great idea, but having hard time with the "unused" identification process. I have been looking into this using minimalcss, but the problem is you need an inventory each page so can be identified on what is needed. Did you have some idea on how this would work?
cc @hectorfhurtado
@tomdiggle couple of questions around how it will work;
- If you introduce it as as flag as part of
stencil startwon't it start cleaning up css as you are making changes to your files or changing id/class names across your templates. You might end of loosing work for an unintended change. - Also how do we know which file was cleaned to test the exact page ? Are we going to display on the console as to which file/line was cleaned up ?
- How will this work with css imports ?
- What happens with scss files do they continue to hold the unused css ?
What happens with scss files do they continue to hold the unused css ?
The scss files would continue to hold the unused css. We only want to remove unused css from the compiled css stylesheet being used by the theme inside the <head> tags.
@carsonreinke I've looked into it a little bit and I'm unsure what is the best way to go about identifying what css is unused.
When running stencil start the css compiling is handled by the cssHandler function located in /server/plugins/theme-assets/theme-assets.module.js. I've tried using uncss (see image below) to remove the unused css by using request.info.referrer as the url. This failed because a javascript error theme-bundle.head_async.js could not be loaded.
Maybe @junedkazi can offer some insight on how to go about using the raw html as a reference point?
@tomdiggle I think this is making an assumption that Sass is compiled on each request, I'm not positive, but pretty sure it is not.
Unless BigCommerce would offer more information or confirm on what compiles the Sass, the approach would have to pre-compile Sass instead with WebPack instead of having it generated by the server. This also offers the ability to have async loading, spitting, etc. Pretty sure BigCommerce would be glad to be rid of this. We have done some work on this and it can be done.
If that was done, you could then use uncss (or some other tool) to provide a list of each URL locally, so that during theme bundling, the Sass file that is built, has the extra CSS removed.
Maybe I am over complicating this, but that is how I understand this.
cc @hectorfhurtado
@carsonreinke Agreed, hopefully it's something that BigCommerce can add soon. It would be a great feature to have.
the approach would have to pre-compile Sass instead with WebPack instead of having it generated by the server.
If I am not completly mistaken, this change would in general allow theme developers to employ different strategies for their post processing etc.
@0dp oh, LOL, you found it!
this change would in general allow theme developers to employ different strategies for their post processing
Yes, it would be all done when packaging the theme.
@0dp oh, LOL, you found it!
this change would in general allow theme developers to employ different strategies for their post processing
Yes, it would be all done when packaging the theme.
This would be amazing!
Any updates on this one? I'm guessing as its all baked into stencil-cli we cant do much?
