myFavShrimp / turf

Macro based compile-time SCSS transpilation, CSS minification, and class name uniquification toolchain inspired by CSS modules.
MIT License
50 stars 2 forks source link

[Feature request] Standalone CSS file instead of binary integration #8

Closed sambonbonne closed 11 months ago

sambonbonne commented 1 year ago

Hello,

Would it be possible to optionnaly generate a .css file instead of integrating all CSS into the WASM binary? This would allow caching on the CSS file URL when serving in production.

I don't know if this is technically feasible but if it is, it would be a nice feature!

myFavShrimp commented 12 months ago

Hey, I think this could be a nice feature that is very much in scope of this project. Can you please help me understand a little better what exactly you need? Do you want turf to output the resulting CSS of all style_sheet! invocations to a single file, or do you want turf to write multiple files (one for each compiled SCSS file or macro call)?

sambonbonne commented 12 months ago

That's a good question!

I tried stylers and their approach is to create a stylers/ directory in the target/ directory with:

Here is an example:

$ tree target/ -L 2
target/
├── stylers
│   ├── css
│   │   ├── closebutton.css
│   │   ├── disconnectedpage.css
│   │   ├── firstrun.css
│   │   ├── mainmenu.css
│   │   ├── popover.css
│   │   └── widget.css
│   └── main.css
├── …

With this approach, developers can chose to use one global CSS file or combine themselves as they want. But I don't know if it would work with turf's internals.

Apart from this feature request, another nice thing from stylers is the style! macro which allows developers to put style directly in Rust code, it's less essential for me but I think it would be another great feature to have. May I open a feature request for that too?

Edit: add tree example

myFavShrimp commented 12 months ago

I think it would be great to make the file generation configurable so that users are able to set the generation path and can decide whether they want a single CSS file, multiple CSS files, or even none at all.

The style! macro indeed seems like a nice feature to have. Although it has some specifics about it that should be discussed separately. Plesse, feel very welcome to open another feature request :slightly_smiling_face:

sambonbonne commented 12 months ago

Thanks for you answer!

I don't know if this solves most of the case but generating all separate files and a global file (like stylers) may be sufficient for people wanting to manage files, separate or not (they can chose as they want)?

Another question would be: should it be configurable globally in Cargo.toml or per-macro with an argument (for more fine-grained but complexe configuration)?

I will definitely open another issue for the style! feature request!

myFavShrimp commented 11 months ago

It might be better to expose the configuration globally in the existing Cargo.toml because turf currently does not really parse the input of the style_sheet! macro and just uses it as a string. Adding such functionality means adding more complexity that isn't really necessary.

My idea was to have two optional config parameters (something like seperate_css_files_path and global_css_file_path) which can both be set independently. This makes it very easy to handle for the user and also for turf itself and the change should be rather small and trivial to implement

sambonbonne commented 11 months ago

I agree, the macro is not complex, it's better to keep it like this. And I think it's better to configure in Cargo.toml to keep the code simple and prevent having configuration in Rust files.

I these are two parameters, they can be set both to true? If yes, it may confuse the user, I would suggest to have two parameters as an object like:

[package.metadata.turf.css_generation]
generate_files = false # put to true to generate file(s), let false if you don't need file generation
separate_generated_files = false # put to true to have one file per macro call, let false if you prefere one global file

Of course those are sugggestions and I am not sure this is the best design possible :sweat_smile:

myFavShrimp commented 11 months ago

I forgot to clarify how I meant the parameters to be used. Both seperate_css_files_path and global_css_file_path would accept a string specifying the path of the global css file or the directory where the separate css files should be created. So a config could look something like the following

[package.metadata.turf]
global_css_file_path = "path/to/global.css" # if set, the `path/to/global.css` file will be created and all compiled styles will be written to it
seperate_css_files_path = "dir/for/separate/css/" # if set, all compiled css files will be saved in this directory

This way users can opt in for a single css file output, multiple files or even both if they need it.

I really like the idea of having both parameters on an object that separates them from the rest of the configuration. I'd like the key to be a bit more specific as almost everything from turf's configuration could be categorized as "css generation". So maybe something like file_output is more fitting:

[package.metadata.turf.file_output]
global_css_file_path = ""
seperate_css_files_path = ""
sambonbonne commented 11 months ago

I really like the idea and the naming you propose seem very nice and understandable!

myFavShrimp commented 11 months ago

Now that most of the details have been clarified, it should be possible to implement this. The earliest I can start is two weeks from now, as I'm busy elsewhere at the moment

myFavShrimp commented 11 months ago

This feature is part of the now released version 0.7.0. If you experience any issues using it, please feel free to open a new issue :slightly_smiling_face:

sambonbonne commented 4 months ago

I'm sorry, I never took time to answer because I wasn't working on the project in which I use Turf but today I updated Turf and tried this feature: of course it works like a charm! Thank you for adding it and for this project!