Feature request: global and component local Sass (or similar)

[kylecordes]

So far, it is straightforward to follow advice in issues or discussion (#123), to add support for component level styles; and this is supported by the VSCode plug-in. But this doesn't provide global Sass support (that is, for the global CSS), and of course must be wired separately (including a build process "around" Sapper for global styles) by each application.

This is a feature request to have either Sass, or more ideally a selection of the common CSS processing tools, available "off the shelf in the box" with Sapper.

I believe this feature is in the spirit of Supper, as it would execute entirely at compile time, and (perhaps with some optimization add-on) continue the Sapper/Svelte goal of doing work at compile time to bridge between concise, fluent application code and small, fast runtime code.

[laurentpayot]

+1 for an integrated global CSS generation from preprocessor files

[antony]

This also relates somewhat to: sveltejs/svelte#1808 with the notion of an "unscoped" style tag.

[maxmilton]

Svelte already has an option to proprocess styles which covers components and rollup/webpack can handle preprocessing global styles. Additionally, sapper has no way of passing in any global build configuration options other than your rollup/webpack config. What are you proposing?

Maybe we just need better documentation with examples of how to set up the most common style preprocessors?

[wighawag]

What would be great is a having a shared preprocessing for both global and local style.
This way we could define sass variable or other general styling globally while still having local scope styling via component style. Such local component style would have access to these global variables.

[antony]

@wighawag I just import my variables file into my components.

[maxmilton]

Each component's preprocessors are run in a separate context so it's not like there's one "local style scope", there's actually many. It's powerful to have that level of encapsulation per component.

I do exactly the same thing as @antony , I use a magic @import which includes all my global vars, mixins, etc. Here's an example: https://github.com/WeAreGenki/minna-ui/blob/master/components/select/src/Select.html#L285

[coolemur]

I tried to do the same as @antony mentioned. Just import styles in each component.

It kinda works but then console lists lots of warnings about unused scss selectors.

(I'm trying to use roolup + scss preprocessing)

Easy way to config global scss would a be nice feature.

[ccinelli]

This is a blocker for me....

[antony]

@ccinelli Can you explain why it is a blocker? There are solutions for component global SASS and also for site wide SASS.

[robertpiosik]

@antony Could you please elaborate how can we set global SASS variables and mixins? Is importing in every component the only solution?

[pngwn]

This can't really be 'blocking', the Global CSS file is right there and you can do anything you want with it. If you need those SASS (or similar) variables inside component style tags then they can be imported and used providing you are using the relevant style preprocessor.

What probably is missing is some way to include extra files in your rollup or webpack config (or something to that effect), right now the bundler configs are handled in a way that is very specific to sapper and any processing of other files has to be handled separately. I think it may be possible to improve this situation.

However, the chance of Sapper getting first class support for SASS, Stylus, LESS, etc. is approximately zero.

[coolemur]

@pngwn Could you explain, why zero? And how you measure this probability? Short documented instructions how to add sass, stylus, less, etc into the build would be enough.

[pngwn]

Because it is not the job of Svelte or Sapper to have opinions about how you should handle your CSS. Svelte's preprocess step allows you to do pretty much anything you want in your components as long as you are careful to transform them into plain Svelte component syntax and plain CSS before that code hits the compiler.

We are currently in the process of writing more documentation explaining how to preprocess your components (amongst other things), so this should be available within a reasonable timeframe. Converting a plain file from SASS etc. into plain CSS can be done with a simple script, there are plenty of tutorials explaining this process. Although, as I said, providing a more elegant way to do this in Sapper might be possible.

[Conduitry]

There are existing ways to have compile-to-CSS languages in your components - via preprocessors. As mentioned, we can do a better job documenting these, and writing a sort of cookbook of typical pieces you can put together will help. But there's nothing we want to do in Sapper or Svelte to have 'first class support' for these. Preprocessors are the support.

Using a compile-to-CSS language in your global styles is even simpler. As mentioned, you can just write a script to compile your files into global.css, and put this in the npm scripts before Sapper is run. The building blocks for this already exist. There's no need to write, maintain, and document hooks for Sapper to run scripts before it performs the compilation when there is an existing extremely well-known way of doing this already - using && in a command line.

[robertpiosik]

I like the idea on not having a lot of opinions but what I would like more is Sapper being more popular than nuxt/next/gatsby, to achieve that, opinions work for ease of development and popularity among less experienced users.