Using PostCSS with @snowpack/plugin-build-script plugin logs error about microsite HOT 6 CLOSED

Yeah probably it's for the config resolution, didn't think of that!

Thought about the postcss integration some more, would prefer no predefined integration but instead setting it in the snowpack config as a plugin like done in Snowpack. Having it kind of integrated but not fully out of the box feels off to me...

from microsite.

Automatic PostCSS configuration has been removed in [email protected]!

from microsite.

There's not a way to disable @snowpack/plugin-postcss right now... Microsite automatically loads it so most users won't need a custom snowpack.config.cjs file. IMO that covers the more common use case (zero config), but I could consider disabling any automatic features like this if a custom snowpack.config.cjs file is detected? My concern is that I really don't want using a custom Snowpack config to feel like you're ejecting from Microsite itself—needing to re-enable out of the box features might start to feel like that?

As a side note, I don't see much a functional difference between the two plugins. The build script is more explicit? Because @snowpack/plugin-postcss executes almost the exact same code as @snowpack/plugin-build-script runs.

from microsite.

Think you are right that it does cover the most common use case.

Regarding a custom snowpack config I did find this function so if I understand correctly the config does get merged, don't think this is documented behaviour?

Indeed there is no substantial functional difference, what I like about the build script is the flexibility, allowing usage of any CLI tool to process files.
Going a bit off-topic here: I do not like tool specific plugins when a flexible alternative achieves the same. Take for example Gulp, when it released almost every package that did processing got a gulp package which wraps the original package. Some give little to no value over using the package directly but with the downside of maintenance churn, upstream issue management and more code. Some packages have there place ofc. for complex behaviour integrating in specific ways with the 'main tool' (Gulp).

A good example is @snowpack/plugin-dotenv, I use dotenv-safe in one snowpack project directly, which is as easy as invoking it in the snowpack config file. Which I love about Snowpack, I can compose existing tools without needing an extra specific wrapper.

Sidenote: I expected @snowpack/plugin-postcss to use the PostCSS JS api directly so there would be no need to spawn an extra process, which makes it even weirder to see it does invoke the command line tool instead...

from microsite.

You're right! Microsite needs some of those overrides to work properly, but some things (like the PostCSS plugin) are just for convenience. That behavior needs to be documented—I'll be sure to call out the PostCSS behavior specifically. It's a bit of a holdover from when PostCSS was built-in to Microsite but was removed for size reasons.

• Totally agree with you on all the points about tool-specific plugins! Ecosystem churn is no fun for anyone.
• I also find the way @snowpack/plugin-postcss works to be pretty weird! I think it's likely because config resolution is built into postcss-cli but not the JS api?

from microsite.

Still nailing down how to implement this in the most convenient way possible, but after giving it some consideration, I agree. Microsite shouldn't be injecting PostCSS into custom configs.

from microsite.