PostCSS support (SASS, SCSS, LESS, PostCSS plugins, etc.)

[lukethacoder]

Is your feature request related to a problem? Please describe.

Building out fully custom LWC components (both functionality and styling) can be a time consuming task. Incorporating PostCSS would greatly improve the front end DX as well as speed up build times. Many folks already have existing front end systems/frameworks setup off the platform. Porting these over to vanilla CSS based LWC's is another time consuming task.

Describe the solution you'd like

Ideally we could drop in a postcss.config.js file at the root of the /lwc folder (next to .eslintrc.json and jsconfig.json). This would allow us to use plugins/frameworks (SCSS/SASS, PurgeCSS, TailwindCSS etc.) as well as autoprefixing our custom CSS.

Describe alternatives you've considered

• Running your own custom config locally (webpack/parcel/rollup etc.), running whatever setup you want, and compiling out to the standard LWC folder and file structure.
• instead of a postcss.config.js specifically, could implement a generic lwc.config.js. more future proof if the addition of webpack/parcel/rollup like functionality came to lwc?
• go one step further and add npm support. adding a package.json file at the root of the /lwc folder. full freedom to develop your components anyway you like (this could also mirror the way lwc.dev + lwc-services works off platform

[diervo]

@lukethacoder I don't think we in general prevent you for using any preprocessing tool you like (same as for example Typescript), however we can't support anything non standard to be uploaded (for compatibility reasons mostly).

As per the package.json, that's something we are starting to look at, but it will take time to adapt some of the OSS practices into platform (lot of legacy code and bugs to navigate though to make it happen). But we indeed would love to start allowing customers to use npm packages for different use cases (in a way that we can guarantee security and backwards compatibility). I would encourage to open a story in AppExchange to push more explicitly for it.

Let us know if there is anything preventing you of using any pre-processor or anyway we can make it more seamless, otherwise for the short term not sure this issue has any actionable execution.

[muenzpraeger]

@lukethacoder great ideas.

In theory there's nothing stopping you from doing any processing using npm packages, like we do here. This would be manual right now (as in: you've to run the commands manual before deploying to an org), and should be more automated once the CLI exposes their support for custom hooks. @clairebianchi can speak to the latter best.

@diervo can speak better than me to bundling npm packages as part of LWCs.

[lukethacoder]

I haven't personally had any issues running a custom setup for building LWC. The only concern I see here is if we are taking on legacy code from a previous vendor (say 2-3yrs down the line). We no longer have all the build/dev tools that they used sitting there on the platform ready to go.

Maybe this is too much of an edge case for now, but it will be interesting to see how changing vendors may affect the upkeep of previous LWCs rocking custom setups. Greenfield projects aren't an issue, keep all your code and build tools backed up in source control and you're good to go.

Definitely understand the security concerns here. Salesforce hosted git (similar to what you guys have set up on Heroku) could be a possibility that would encourage keeping the build tools and code on the platform, solving the vendor swapping issue? Could also bring visibility of CI/CD and deployments to admins which would be neat. Quite a wild idea, but will see where you guys take it.