Here's a way to setup webpack to run Svelte component css through postcss.



## Svelte CSS Preprocessing

Svelte is a magical disappearing framework for authoring ui components for the browser.  And it took a bit of magic to get preproocessing working right.

Svelte takes the approach of web components and polymer in that it puts all your markup, styles, and scripts in one file.  

Recently, Svelte has added the ability to preprocess each of these parts of your component files.  This is done by providing the svelte compiler with hooks for `markup`, `style`, or `script` respectively.

## CSSNext in Svelte

I like the idea of writing css in my components.  But I also want to write the latest/greatest css.  For that, I'll use some [cssnext](http://cssnext.io/).  But this won't work in all browsers yet, so it needs preprocessed.

As a simple example, I might want my css to be able to import 3rd party css from npm or transpile away variable usage in this kind of css code in my `src/badge.html` svelte component file.

```html
<style>
@import "@pluralsight/ps-design-system-core";
.badge {
  display: inline-block;
  color: #fff;
}
.badge--color-red {
  background-color: var(--psColorsRed);
}
</style>
```

But to do that, we'll need a little configuration.  For the build, I'll use Webpack.  I'll use [`svelte-loader`](https://github.com/sveltejs/svelte-loader) to compile the Svelte component.

For the css, Svelte gives us a couple options: make the compiled component js dynamically add `style` tags for css upon DOM insertion or export a `.css` file with all styles at build time.

Based on the option you pick, your Webpack setup will be different.  Here are both methods:

## Method 1: Components Insert Styles

For this option, we are going to only need `svelte-loader`, and we'll set it up to preprocess its own styles via the svelte preprocessor hook.  In `webpack.config.js`, we'll write:

```js
const path = require('path')
const postcss = require('postcss')
const postcssCssnext = require('postcss-cssnext')
const postcssImport = require('postcss-import')
module.exports = {
  // ...
  module: {
    rules: [
      // ...
      {
        test: /\.(html|svelte)$/,
        include: [path.resolve('src')],
        use: [
          {
            loader: 'svelte-loader',
            options: {
              style: ({ content, attributes, filename }) => {
                return postcss([
                  postcssImport,
                  postcssCssnext({
                    browsers: ['Last 2 versions', 'IE >= 11']
                  })
                ])
                  .process(content, { from: filename })
                  .then(result => {
                    return { code: result.css, map: null }
                  })
                  .catch(err => {
                    console.log('failed to preprocess style', err)
                    return
                  })
              }
            }
          }
        ]
      }
    ]
  }
}
```

Note that `options` for `svelte-loader` receives a `style` hook.  Inside that function, the source css is passed as `content`.  That `content` is what we pass to the `postcss.process` function.

If the `style` hook returns nothing, no preprocessing will happen, so make sure to return the Promise of the `postcss.process` call.  The shape of the data returned by the Promise must be `{ code: 'new css string', map: {} }`.  This code disregards the source map because currently Svelte does too.

This `postcss.process` call is happening per file, and that file directory context is provded to the `postcss-import` plugin (and others that need it) via the `from` option passed to the `postcss.process` call.

Run `webpack` and the outputted `.js` file should contain code to insert the postcss-processed css.

## Method 2: Emit External CSS

For performance reasons, you might like to build an external `.css` file instead of doing dynamic style insertions at runtime.  For this, we're going to setup our loaders differently.  

First, we'll add an `emitCss: true` option to the `svelte-loader`:

```js
const path = require('path')
const postcssCssnext = require('postcss-cssnext')
const postcssImport = require('postcss-import')
module.exports = {
  // ...
  module: {
    rules: [
      // ...
      {
        test: /\.(html|svelte)$/,
        include: [path.resolve('src')],
        use: [
          {
            loader: 'svelte-loader',
            options: {
              emitCss: true
            }
          }
        ]
      }
    ]
  }
}
```

You'll also notice that the config for preprocessing doesn't exist in the `svelte-loader` options any more.  It has moved and changed a bit.

Instead, now we use a CSS loader chain like you might be more used to.  Add this to your `webpack.config.js` `module.rules`:

```js
const ExtractTextPlugin = require('extract-text-webpack-plugin')
// ...
{
  test: /\.css$/,
  exclude: /node_modules/,
  use: ExtractTextPlugin.extract({
    fallback: 'style-loader',
    use: [
      {
        loader: 'css-loader',
        options: { modules: true, sourceMap: true }
      },
      {
        loader: 'postcss-loader',
        options: {
          plugins: [
            postcssImport({
              addModulesDirectories: [
                path.resolve(path.join(__dirname, 'node_modules'))
              ]
            }),
            postcssCssnext
          ]
        }
      }
    ]
  })
}
```

And this bit in your `plugins` portion of `webpack.config.js`:

```js
plugins: [
  new ExtractTextPlugin('styles.css'),
]
```

There are a few important bits to note here.

We are using `exclude` over the more precise `include` option on the loader because of the fact that the `svelte-loader` is emitting our CSS into temporary directories (like `/private/var/folders/77/58asdf/T/svelte-183827797.css`) for preprocessing before the final webpack output destination.  Since we don't know where that temp directory will be, we can't include it and will thus exclude what we know we don't want processed by this loader.

The fact of the temp directories causes us to have to do additional config to the `postcss-import` plugin.  We have to show it where our project's `node_modules` directory is because when preprocessing happens in the temp directory, the module resolution process can't do what it usually does by default -- recursively traverse `node_modules` directories from `process.cwd()`.  This is because the file's not even in our project's directory tree.

Using this mode of configuration, after we run `webpack`, we should see a `styles.css` file output with our processed stylesheet.

That should do it, and I'm happy that it works.  For a working codebase that's has working svelte postcss processing, check out my [svelte-with-react](https://github.com/jaketrent/svelte-with-react) repo.

Do you have a slick way to setup CSS preprocessing in Svelte?

How to setup webpack to run Svelte component css through postcss.

Preprocess Svelte Components with Postcss

The ecosystem that CSSNext lives within can be confusing to name and navigate.  Here's how I see the pieces fitting together.



## PostCSS

Before we get to CSSNext, let's visit [PostCSS](https://github.com/postcss/postcss).  PostCSS provides transform functions for CSS.  These functions are written in JavaScript.  PostCSS can assemble one or more of these transform functions into a transformation pipeline for your CSS.

Generally PostCSS is adding or changing the functionality of vanilla CSS, usually to make it do something cooler and newer than before. 

PostCSS doesn't contain any transforms itself.  Rather it is a platform for running plugins that you assemble.  In this way, it's like [Babel](http://babeljs.io/), which won't transform JavaScript until you add plugins and presets.

PostCSS can be compared to a preprocessor like Sass or LESS.

## CSSNext

[CSSNext](http://cssnext.io/) is a plugin to PostCSS.  More precisely, it's called `postcss-cssnext`, prefixed with `postss-*` as most PostCSS plugins are.  The library used to be called `cssnext`, but it was renamed to `postcss-cssnext`.  It's still sometimes referred to as "CSSNext".

Going back to the Babel analogy, CSSNext is similar in a couple ways:

CSSNext is like the `babel-preset-stage-*` presets in that it is anticipating the eventual adoption and implementation of new CSS specs by the browsers.  These specs haven't been fully implemented today, so CSSNext allows us to use them in our source CSS, compiling them down to browser-ready CSS through PostCSS.

CSSNext gathers togther many `postcss-*` plugins, each supporting some single new CSS spec feature.  In this way, it's like a Babel preset, or collection of plugins.  The [dependency list](https://github.com/MoOx/postcss-cssnext/blob/master/package.json#L23) should give you a nice view of what it includes.  Another [rundown of features](http://cssnext.io/features/) is on their website.

## What to Call It?

So what do you call your source code?  You're writing CSS using future features via CSSNext.  It's processed via PostCSS.  The file extensions are still usually just `*.css`.  I've just been calling it "CSSNext", as in, "I'm writing CSSNext", or "the styles are  in CSSNext".  

When referring to the tech stack of a project, I'll sometimes say, "It's built on PostCSS".  This is ambiguous and sometimes assumes a lot, since a pipeline of PostCSS plugins could provide all sorts of varied functionality.

What do you call these things?  And how do you frame what PostCSS and CSSNext are in your mind?

The ecosystem that CSSNext lives within can be confusing to navigate.  Here's how I see the pieces fitting together.

What is CSSNext?

How to set fallbacks for CSSNext variables for which values aren't present.



## CSSNext Variables

[CSSNext](http://cssnext.io/) is a library that allows you to use tomorrow's CSS syntax and features today -- much as Babel does for JavaScript.  One such feature is CSS variables.  

The variables are defined like:

```css
:root {
  --superHot: red;
}
```

And then to use the variable:

```css
.vrOfTheFuture {
  color: var(--superHot);
}
```

And it's awesome -- variables in CSS (of the future).

## Lack of Fallback

But in the case that the variable isn't present, you have a problem.  Color doesn't get set at all in the above example of `.vrOfTheFuture`.  The variable value might not be present for any number of reasons: you forgot to import it or merely misspelled it.

Your CSS compiler will likely give you an error like:

```
(Emitted value instead of an instance of Error) postcss-custom-properties: 
/Users/.../my.css:24:3: variable '--superHot' is undefined and used without a fallback
```

As you can see in the error report, CSSNext gets its variable support from a subdependency library, [`postcss-custom-properties`](https://github.com/postcss/postcss-custom-properties).  In fact, CSSNext is simply a collection of [postcss libraries](https://github.com/MoOx/postcss-cssnext/blob/master/package.json) whose combined features are present or expected in the CSS spec.

## Setting a Fallback

A fallback is the value that will be used in the case that the variable is unavailable.  To set it, pass it as the second value to `var()`, like this:

```css
.vrOfTheFuture {
  color: var(--superHot, fuchsia);
}
```

Fallback present.  Superhot might look a bit odd when the fallback is used, but at least we have a fallback color.

Do you ever end up using fallbacks?  What are your favorite uses?

How to set fallbacks for cssnext variables for which values aren't present.

CSSNext Variable Fallback

PostCSS offers JavaScript-based CSS processing.  It's easy to make a plugin for this system.  Let's do it!



## What is PostCSS?

PostCSS is a system that uses Javascript to parse and process CSS.  This means that if your JS can adjust your CSS, you can use the new, zany, or made-up features of CSS. PostCSS can compile it down to browser-ready CSS.  This makes PostCSS a lot like the Babel.js of the CSS world. 

PostCSS has little in the way of CSS processors built into it.  You have to provide it an array of processor plugins that you want your CSS to pass through:  

```js
postcss([<yourProcessorsHere>])
```

PostCSS provides a common API for each of these plugins to talk and then orchestrates the process.

## Invoking PostCSS Programmatically

We'll look at the programmatic PostCSS API here, but there are other ways of interacting with PostCSS, such as Webpack's [postcss-loader](https://github.com/postcss/postcss-loader).

PostCSS is exported as a single function that takes as an argument an array of your plugins.  We'll feed it our custom plugin, `postcss-css-var-selectors` and one more to show chain-ability -- a popular one, [autoprefixer](https://github.com/postcss/autoprefixer).  It returns an object on which you can call `process`, passing your source CSS:

```js
const { promisify } = require('util')

const autoprefixer = require('autoprefixer')
const fs = require('fs')
const postcss = require('postcss')

const postcssCssVarSelectors = require('./postcss-css-var-selectors')

;(async _ => {
  const css = await fs.readFile('./source.css', 'utf8')
  const { processedCss } = 
    await postcss([postcssCssVarSelectors, autoprefixer]).process(css)
})()
```

As you can tell, the `postcss.process` function is async and returns a Promise.

## PostCSS Plugin Public API

A plugin signature is a function takes `options` and returns a function that processes PostCSS-parsed CSS:

```text
options -> css -> ()
```

The parsed CSS object is mutated in place (not returned).  `options` is simply a JS object that contains any options that you want your plugin to adjust to.

To tell PostCSS about your plugin, you'll have to register it before using it:

```js
const postcss = require('postcss')

postcss.plugin('css-var-selectors', options => {
  return css = {
    // ...
  }
})
```

The first argument to `postcss.plugin` is the name of your plugin.  By convention, plugins are prefixed with `postcss-` and have dashified names.  When you identify the name of your plugin in this function call, just drop the prefix. 

## Example PostCSS Plugin

I'm quickly going to show an implementation of a `postcss-css-var-selectors` plugin.  This plugin will convert cssnext variables into vanilla CSS utility classes.  That is, convert this:

```css
:root {
  --colorsRed: red;
  --colorsPurple: rebeccapurple;
}
```

into this:

```css
.colors-red { color: red; }
.colors-purple { color: rebeccapurple; }
```

There is an extensive and powerful [PostCSS API](http://api.postcss.org/global.html).  This example will showcase just a few important bits of the PostCSS API.  First, the source of `postcss-css-var-selectors.js`:

```js
const dashify = require('dashify')
const postcss = require('postcss')

const defaultOptions = {
  formatPropName(name, options) {
    const tests = Array.isArray(options.propNameTests) ? options.tests : []
    const match = tests.find(t => t.match.test(name))
    return match ? match.prop : options.defaultPropName || 'color'
  }
}

const createSelectorForVar = (decl, options) => {
  const prop = dashify(decl.prop)
  const value = decl.value
  return postcss.parse(`
.${prop} { ${options.formatPropName(decl.prop, options)}: ${value}; }
`)
}

module.exports = postcss.plugin('css-var-selectors', options => {
  return css => {
    options = Object.assign({}, defaultOptions, options)

    css.walkRules(rule => {
      rule.walkDecls((decl, i) => {
        const isCssVar = /^--/.test(decl.prop)
        if (isCssVar)
          decl.root().insertAfter(decl.root(), createSelectorForVar(decl, options))
      })

      const isCssVarRoot = rule.selector === ':root'
      if (isCssVarRoot) rule.remove()
    })
  }
})
```

A couple interesting bits:

- `css.walkRules` will allow you to iterate through all the CSS selectors
- `css.walkDecls` will allow you to iterate through all the attributes per selector
- You can create a new selector (PostCSS `Node`) by invoking `postcss.parse` on a string of new CSS you dream up. For example: `postcss.parse('a { color: inherit }')`.

And just for completeness of the example, here are the options for making the formatting conversion that you might pass:

```
const propNameTests = [{ match: /colors/, prop: 'color' }]
// ...
const { processedCss } = await postcss([
    postcssCssVarSelectors({ propNameTests }), 
    autoprefixer
  ]).process(css)
```

Now this is just an example of what a particular plugin might do to process CSS.  Your plugin can be whatever you need or whatever you imagination dreams up.

What else have you done with PostCSS plugins?  And how else have you constructed them that has worked well for you?

Postcss offers JS-based CSS processing.  It's easy to make a plugin for this system.

How to Make a Postcss Plugin

The `"style"` attribute in package.json is useful for importing CSS packages.  Here's a way to utilize it.



## CSS on NPM

NPM is a great channel for distributing assets for JavaScript projects.  Traditionally, JavaScript code has been the most common thing to be stored in NPM, and that's what the repository was built for.  But there's nothing that really precludes storing other things in the repository, such as CSS.

UI components stored in NPM provide a compelling reason to store the CSS there as well.  UI components usually have a code or markup portion matched with some styles.  These styles are often stored in a `.css` stylesheet alongside the JavaScript. 

## Loading CSS from NPM

To get CSS out of NPM, you install it just like anything else:

```
npm install some-stylesheet-package
```

Once it's on your filesystem, you could reference it in `node_modules` straight from a script tag:

```html
<script src="node-modules/some-stylesheet-package/css/index.css"></script>
```

This bypasses any usage or need for the `"style"` attribute in `package.json`. There is probably a more sophisticated and flexible option with the use of a module loader like [webpack](https://webpack.js.org/).  Webpack provides [loaders](https://webpack.js.org/concepts/loaders/) that define how to transform source code (eg, '*.css') into something that your code can import and use.  

One of my favorite CSS loader stacks includes [postcss-loader](https://github.com/postcss/postcss-loader).  This loader, and [postcss](https://github.com/postcss/postcss) generally, has many plugins that allow it to do interesting things with CSS.  Of particular interest is the [postcss-import](https://github.com/postcss/postcss-import) plugin.  It's going to make use of the `"style"` attribute in `package.json`.

## postcss-import Uses "style"

`postcss-import` has a main purpose of inlining styles that it imports.  And there are some potential [hangups](/post/css-module-selectors-pileup-with-postcss-import/) to watch out for there.  The other great thing about it is that it helps us properly import CSS from the NPM packages like we've been talking about.

If I have a local stylesheet that imports the `some-stylesheet-package` that we just installed, `postcss-import` will help get it right.  In `local.css`, we see the import:

```
@import "some-stylesheet-package";

/* ... */
```

`postcss-import` will look in a number of places to make that import work.  Importantly, it considers the `"style"` attribute in the `package.json` file.  If the package author has specified this field, it will be the entry point for the CSS import.  The `some-stylesheet-package` `package.json` that includes this attribute:

```
{
  "style": "css/index.css"
}
```

Would direct the module loader to import the CSS from:

```
node_modules/some-stylesheet-package/css/index.css
```

## A Standard?

This approach is becoming more widely used, but is it really a standard yet?  It's a convention, at least, that a number of tools support the use of.  It would be great if this continues to develop to the point of being on more sure footing.  Right now, it seems like it's a de facto standard.  I would love to see it gain more official community or NPM support.

Do you use the `"style"` attribute in your `package.json`?  What tooling do you use around it to support and use it?

The 'style' attribute in package.json is useful for importing CSS packages.

Package.json "style" Attribute

Use of postcss-import in your CSS module processing can lead to more selectors than you realized.  Here are some ways to deal with it.



[postcss-import](https://github.com/postcss/postcss-import) is a useful [postcss](http://postcss.org/) plugin.  It allows loading CSS from npm modules by looking up module entry [via `package.json`'s `"style"` attribute](https://github.com/postcss/postcss-import/blob/ac9903b658b1d447f62b9021081051e8b8d42538/lib/resolve-id.js#L22). But if you don't realize that one of its main features is inlining what you `@import`, the consequences can be unexpected.  So what can you do?

## If You Don't Use postcss-import

It's one option to just not use it.  But the plugin does seem to smooth out importing.  You're able to import from `node_modules`, `web_modules`, and utilize that `package.json` `"style"` attribute.  So, I'm keeping it.  Ok, where from here?

## Scenario

Let's say that I have a source CSS file that I'm building into a module with [`css-loader`](https://github.com/webpack-contrib/css-loader), called `source.css`:

```css
.mySelector {
  color: red;
}
```

And something that wants to be imported, `dependency.css`:

```css
.dependencySelector {
  outline: 1px solid blue;
}
```

## No @imports Yet

If I don't import my dependency, then the export object for the `source.css` CSS module will look like:

```
{
  mySelector: "mySelector___oHNuy"
}
```

This is as expected.  No surprises.

## Top-level @import

If we make sure our [`postcss.config.js`](https://github.com/postcss/postcss-loader#config) is running with `postcss-import`:

```js
module.exports = {
  plugins: {
    'postcss-import': {}
  }
}
```

And then add an `@import` of the dependency to our `source.css`:

```css
@import "./dependency.css";
.mySelector {
  color: red;
}
```

We've done nothing to use the dependency or compose with it, but our module export object still changes to:

```js
{
  dependencySelector: "dependencySelector___2HjUz"
  mySelector: "mySelector___oHNuy"
}
```

This is because `postcss-import` is *inlining* everything we `@import`.

## Composes with Top-level Import

Once we use the imported dependency in a `composes` attribute:

```css
@import "./dependency.css";
.mySelector {
  composes: dependencySelector;
  color: red;
}
```

We change the output of the `mySelector` value, where both selector values now are composed:

```js
{
  dependencySelector: "dependencySelector___2HjUz"
  mySelector: "mySelector___oHNuy dependencySelector___2HjUz"
}
```

## Composes From

But let's say that we want to avoid having `dependencySelector` appear in our CSS modules export object.  We can use the `composes: <selector> from <import-path>` syntax:

```css
.mySelector {
  composes: dependencySelector from "./dependency.css";
  color: red;
}
```

This will yield the following CSS module export object:

```js
{
  mySelector: "mySelector___oHNuy dependencySelector___2BS8K"
}
```

This is because the `@import` of the dependency is done within the scope of the `.mySelector` selector, not the entire module.

## Import Variables

There's another way I've gotten around this issue.  That is to `@import` only variables.  If it is only variable values that you need, you can separate them into another file and import them without worrying about cluttering your CSS module export object.  Since this is one of the style elements that we share most often, it works pretty well.

Let's make a new file, `dependency-vars.css`:

```css
:root {
  --aDependencyVar: orange;
}
```

Then if I use it, even if imported at the top-level:

```css
@import "./dependency-vars.css";
.mySelector {
  color: red;
  border: 1px solid var(--aDependencyVar);
}
```

It still yields an uncluttered CSS module export object:

```js
{
  mySelector: "mySelector___oHNuy"
}
```

Have you run into this issue?  Or is it a non-issue for you?  What are some other ways that you've addressed it and kept your CSS modules uncluttered?

Use of postcss-import in your CSS module processing can lead to more selectors than you realized.