Initial release checklist

[43081j]

This is an attempt at implementing a custom syntax for PostCSS, primarily so we can use stylelint against lit projects.

Before it is usable, here's what is to do:

• Ensure location correction works as expected. We already correct the locations but we don't account for the change in position caused by us replacing expressions with a CSS comment
• Decide if replacing expressions with a CSS comment is the right decision #6
• Write tests for the parser
• Prove it works with stylelint (test: add tests for stylelint integration #8)
• Prove it works with PostCSS
• Implement the serializer so we can also transform CSS inside templates (feat: implement syntax stringifier #5)
• Write tests for the serializer (feat: implement syntax stringifier #5)
• Figure out what options we should be calling @babel/parser with and if we can infer from the consumer's babelrc file
• Support typescript files

Any help with this will be appreciated, the location info will be the pain point i think. i've been down that road before with lit's eslint plugin, fun but insane...

I left a console.log in the main file right now to test parsing a string, too. FYI

cc

@jeddy3 - since your reply in the other issue today, this is where i got to. still a way to go but maybe you can let me know if its the right direction

@bennypowers @abdonrd you may be interested too

@stramel if you're curious 😂

[43081j]

Location info correction

We have a location info correction walker here.

Its purpose is to correct a PostCSS location by offsetting it with the original JS location it came from.

For example, if our css template is 10 lines into the JS file, we need to offset all of our PostCSS locations by 10 lines.

This is already implemented (though untested).

However, we will have incorrect locations when expressions are used:

css`
  .foo { color: ${'blue'}; }
`;

Will become:

  .foo { color: /* PLACEHOLDER */ }

Which means the end position of this stylesheet will be off by PLACEHOLDER_LENGTH - EXPR_LENGTH.

This only matters for end positions, I think. We need to think of some way to correct the line and column based on any expressions that were in there originally (expressions can be multi-line).

[jeddy3]

since your reply in the other issue today, this is where i got to. still a way to go but maybe you can let me know if its the right direction

I'm afraid I don't know much about writing syntaxes.

My only suggestion is calling this postcss-lit and making it specific to lit templates. The postcss-css-in-js was monolithic, but there's too much diversity in the css-in-js libraries for it to be sustainable. There's probably less diversity in template literal libraries, but still some. You may find it useful to limit the scope of the syntax.

[43081j]

no worries, i'll figure it out. i've gone ahead and renamed the package too.

finally got the location resolution working, too 🙌

[43081j]

for anyone lurking:

all of this is done now. once postcss/postcss#1675 is merged, i can merge the remaining PRs and publish.

some similar postcss syntaxes do exist, but i figure its nice to have a lit-specific one anyway we can keep more focused and maintained.

it works as a postcss syntax and a stylelint syntax just fine

[43081j]

everything is merged, will publish tonight. closing this now 👍