postcss-styled-syntax
PostCSS syntax for template literals CSS-in-JS (e. g. styled-components, Emotion). It was built to be used as Stylelint custom syntax or with PostCSS plugins.
Syntax supports:
- Full spectrum of styled-components syntax
- Deeply nested interpolations
- Interpolations in selectors, property names, and values
- JavaScript and TypeScript (including files with JSX)
- All functions:
styled.foo``
styled(Component)``
styled.foo.attrs({})``
styled(Component).attrs({})``
styled.foo(props => ``)
styled(Component)(props => ``)
css``
createGlobalStyle``
let Component = styled.p`
color: #bada55;
`;
Install
npm install --save-dev postcss-styled-syntax
Usage
Stylelint
Install syntax and add to a Stylelint config:
{
"customSyntax": "postcss-styled-syntax"
}
Stylelint custom syntax documentation.
PostCSS
Install syntax and add to a PostCSS config:
module.exports = {
syntax: 'postcss-styled-syntax',
plugins: [ /* ... */ ],
};
An example assumes using PostCSS CLI or another PostCSS runner with config support.
How it works
Parsing
Syntax parser JavaScript/TypeScript code and find all supported components and functions (e.g., css``
). Then, it goes over them and builds a PostCSS AST, where all found components become Root
nodes inside the Document
node.
All interpolations within the found component CSS end up in the AST. E. g. for a declaration color: ${brand}
Decl
node will look like this:
Decl {
prop: 'color',
value: '${brand}',
}
When interpolation is not part of any node, it goes to the next node's raws.before
. For example, for the following code:
let Component = styled.p`
${textStyles}
color: red;
`;
AST will look like:
Decl {
prop: 'color',
value: 'red',
raws: {
before: '\n\t${textStyles}\n\n\t',
// ...
}
}
If there is no next node after interpolation, it will go to parents raws.after
. For example, for the following code:
let Component = styled.p`
color: red;
${textStyles}
`;
AST will look like:
Root {
nodes: [
Decl {
prop: 'color',
value: 'red',
},
],
raws: {
after: '\n\n\t${textStyles}\n'
// ...
},
}
Stringifying
Mostly, it works just as the default PostCSS stringifyer. The main difference is the css
helper in interpolations within a styled component code. E. g. situations like this:
let Component = styled.p`
${(props) =>
props.isPrimary
? css`
background: green;
`
: css`
border: 1px solid blue;
`}
color: red;
`;
css
helper inside an interpolation within Component
code.
During parsing, the whole interpolation (${(props) ... }
) is added as raws.before
to color: red
node. And it should not be modified. Each css
helper remembers their original content (as a string).
When stringifyer reaches a node's raws.before
, it checks if it has interpolations with css
helpers. If yes, it searches for the original content of css
helper and replaces it with a stringified css
helper. This way, changes to the AST of the css
helper will be stringified.
Known issues
-
Double-slash comments (//
) will result in a parsing error. Use standard CSS comments instead (/* */
). It is definitely possible to add support for double-slash comments, but let's use standard CSS as much as possible
-
Source maps won't work or cannot be trusted. I did not disable them on purpose. But did not test them at all. Because of the way we need to handle css
helpers within a styled component, source.end
positions on a node might change if css
AST changes. See the “How it works” section on stringifying for more info.
Acknowledgements
PostCSS for tokenizer, parser, stringifier, and tests for them.
Prettier for styled-components detection function in an ESTree AST.