pattern-lab / patternlab-node

The Node version of Pattern Lab
http://patternlab.io
MIT License
2.05k stars 406 forks source link

evaluate official sass support #1043

Closed bmuenzenmeyer closed 5 years ago

bmuenzenmeyer commented 5 years ago

did sass win?

do we want to re-integrate a tool that complicates our life? folks inevitably want to integrate sass and watching sass and knowing when it changes into their own workflow. we emit events on watched files for this reason

would something like a real honest-to-goodness plugin, like @pattern-lab/plugin-sass work?

bmuenzenmeyer commented 5 years ago

would documentation be enough?

This all came about because the stellar starterkit-handlebars-demo only ships with scss currently

JosefBredereck commented 5 years ago

I would love to see that. But if you consider including something like auto prefixing and other plugins the people would like to see, you will need functionalities like webpack or gulp have.

sghoweri commented 5 years ago

In my opinion I think the most important thing is that we have hooks and events (and docs / examples) to tightly integrate Pattern Lab with the crazy number of different tools / workflows out there.

Do we go with vanilla node-sass vs Webpack or Rollup with Sass plugins, etc? If we’re supporting Sass does that almost mean we also support all of the config options Sass provides (custom functions / importers) to extend Sass’s functionality? Do we also support PostCSS?!

I’m not opposed to shipped pre-packages solutions to make stuff like this super easy to get up and running... I just think those pre-built options should be using public APIs that the community can tap into when solving stuff we can’t even think of right now. 😉

JosefBredereck commented 5 years ago

That's what I mean. I would rather rely on packages that handle that stuff and are well implemented and developed for years than building all that stuff by myself and possibly produce bugs.

I'm thinking about a node webpack edition which includes the possibility to preprocess all my assets before it is served by pattern lab. That would preserve not only the possibility to compile sass, it would give far more opportunities. You can decide by yourself if you want to use less, sass with PostCSS or additional javascript compilers like typescript.

JosefBredereck commented 5 years ago

This is already a good project https://github.com/Comcast/patternlab-edition-node-webpack maybe you could invite the devs to include their work for Pattern Lab v3 to this Repro.

bradfrost commented 5 years ago

👋Hey there! Just chipping in with my 2 cents. I don't think it makes sense to compile Sass in this project, as that does open the door to everything else (autoprefixer! SVG! every other thing!)

I think Pattern Lab needs to point people to solid setups and include plenty of links in the documentation. I don't think we need to take on the work of providing webpack/Gulp/whatever setups, but we need to show a reduced example of how that works, and perhaps point elsewhere for a getting started thing.

bmuenzenmeyer commented 5 years ago

I don't think it makes sense to compile Sass in this project, as that does open the door to everything else

Amen. This would be repeating the sins that made edition-node-gulp so complicated. The work within core to expose events feel correct.

People that need simple sass support can do it with surprisingly little effort, as evident in the starterkit-handlebars-demo

"build": "cd dist/css && npx node-sass style.scss style.css"

This isn't the end all, of course. I appreciate the discussion generated by the question and feel it servers as good community validation of the efforts and direction that have been in place for some time now. If specifics of the current system need shoring up, let's address those.