Deprecate in favour of postcss plugins or tools like cssnext about preprocessor HOT 25 CLOSED

So I'm thinking that postcss-cli could be viable, but it there is a known issue with postcss-import and 5.x compat currently - postcss/postcss-import#75

I suppose the main reason to use it would be to swap the existing packages over with little fuss, but it does mean each one would need several additional dependencies instead of just one.

One nice touch of postcss-cli is allowing the options to reside in a JSON file which could help.

cssnext is also another option but when I looked at what plugins are actually needed to build SUIT packages it's quite small compared to the several that cssnext provides, so I've always opted to construct the exact pipeline needed per project.

A postcss-suit plugin is an option too (similar to rework-suit) but that felt quite similar to cssnext also.

Thoughts?

from preprocessor.

The benefits of picking a tool like cssnext could include no maintenance burden, fewer dependencies, clear docs. We might also want to move all these individual components into the main suit repo so they can be developed together with one set of tools...and published as individual packages to npm.

from preprocessor.

I think cssnext is the easiest way to go. Avoiding having to deal with our own build process and config is a big win.

from preprocessor.

no maintenance burden, fewer dependencies, clear docs

Very good points. That kind of decides it.

from preprocessor.

Has anyone tried to compile Suit Components with cssnext? If that didn't work for you, would it make sense to write a wrapper around it or a custom preprocessor using postcss to make suitcss/preprocessor backwards compatible? @necolas (Twitter) & others do you care about backwards compatibility?

from preprocessor.

It has worked fine for me in the past, and I did do it that way for a while. Once I realised I only needed a handful of the actual plugins in cssnext (plus wanting to mix others into the pipeline) I moved away from it. However I would agree that for sake of simplicity using cssnext to build SUIT packages would be good

from preprocessor.

Same for me, I have done it without complication, but currently use my own set of postcss plugins.

from preprocessor.

I was thinking that maybe we can deprecate preprocessor and create a yeoman generator to create suitcss preprocessors like the following:

postcss()
.use(postcss-import)
.use(suit-comformance)
.use(plugins)
.use(autoprefixer)

where plugins are custom plugins, or a bundle like cssnext, or the current set of suitcss plugins (rework-suit).

from preprocessor.

Looking back on this, I think the idea of using just the plugins necessary is a good start. After all, cssnext is just a collection of all of those and they are maintained independently so we don't lose any maintenance overhead.

This whole tool could be replaced with postcss-cli and a list of the needed plugins in a JSON file.

from preprocessor.

@simonsmith I'm good with that

from preprocessor.

I like @simonsmith's initial thinking around constructing the exact pipeline each project needs, such that we can:

• Keep the build as simple and modular as possible
• Avoid surprises that can occur when the css-next-big-thing is refactored
• Isolate build issues per plugin / module
• Get more flexibility to experiment / prototype with features that css-next-big-thing might not support
• Upgrade parts in the event that something better comes along (underscore vs. lodash).

It would be great if it also supported agile development / watching with browsersync, etc.

from preprocessor.

It would be great if it also supported agile development / watching with browsersync, etc.

I think this should be as simple as possible, just a list of postcss plugins. Baking that stuff in seems way of out scope to me.

from preprocessor.

I think this should be as simple as possible, just a list of postcss plugins. Baking that stuff in seems way of out scope to me.

@timkelty I'm a little surprised because you seem to like the idea here?
suitcss/suit#115

I'm not necessarily leaning toward any one solution. I do like to have the ability to easily add features as they start to make sense in terms of maximizing productivity both for users and maintainers, and to switch out packages that are under performing or obsolete.

Something in line what what is done in this article, Breaking up with Sass, seems like it serves as a good cross section for the various ideas discussed so far.

from preprocessor.

Also seems like cssnext is moving to just a postcss plugin anyway - https://github.com/cssnext/postcss-cssnext#readme

I vote deprecate this repo and all the components move to using postcss in their relevant package.json files. We coud do something like in npm run build:

postcss -u postcss-import -u autoprefixer -u postcss-custom-media -d build -o build.css

Or include a config json file in each repo if that gets too unwieldy.

from preprocessor.

@timkelty I'm a little surprised because you seem to like the idea here?

For me the difference is including as part of the preprocessor vs. part of the testing suite. If we can get BS to pop open browsers at all different breakpoint widths when running a test, I'm all for that.

from preprocessor.

@simonsmith the postcss-cli option sounds good to me. The other option would be to pick another task runner (Gulp, etc) and run Postcss through there.

When it comes down to it, aren't we mostly just talking about what our test suite is going to run? It seems like most people using this would be feeding it into an existing postcss pipeline...could be wrong though?

from preprocessor.

I think the focus of this issue is replacing this pre-processor with postcss. Implementing a browser testing solution is not trivial and is definitely a separate task.

I think a good approach for now is get all the packages of the dead rework ecosystem.

Thoughts?

from preprocessor.

Just read up on it some more, and it seems like we can easily wrap postcss in gulp if we need to augment the workflow later on, so 👍

from preprocessor.

@simonsmith agreed - migration to Postcss should be top priority.

As far as how to build Postcss, I think our viable options are:

• use postcss-cli
• use Gulp or another build tool to run things through Postcss

A postcss-suit plugin is an option too (similar to rework-suit) but that felt quite similar to cssnext also.

I didn't include making a postcss-suit plugin, as I don't think it solves any problems. We would still need something on top of that that actually did the build.

from preprocessor.

I'm not sure what advantage gulp would bring. It tends to be the right tool when you want to perform several different transforms on a stream, but here we just want to run one plugin.

Also, in every project I've used SUIT in I've found there already tends to be a pipeline setup (be it gulp, grunt or whatever) and the CSS files can be put through that directly after being installed via npm. Be interested to know other experiences.

I've kinda seen the npm run build tasks as a lightweight way to build the SUIT packages if you need it, but for more complex projects they tend to have their own build pipelines already.

I didn't include making a postcss-suit plugin, as I don't think it solves any problems

Agreed, scrap that idea

from preprocessor.

@simonsmith Agreed about Gulp, just wanted to list our options.

So I think we're on the same page?
Proceed converting everything to Postcss, and use postcss-cli.

from preprocessor.

Sounds good to me. Maybe we can get a PR on one component to see how it works and discuss it there.

from preprocessor.

+1 for @simonsmith's idea.

from preprocessor.

Yesterday @giuseppeg and I had a discussion about how viable this is and what we'd lose (bower support, issues, PRs and git tags) and it seems like a lot to give up vs the gain. Plus the tooling for a monorepo isn't massively easy.

I think we're leaning towards refactoring this tool to use a handful of PostCSS plugins directly. It could have the bem-linter rolled in, and perhaps even stylelint. Would also consider simplifying it by removing the minification option, and leaving that up to to existing build pipelines that most users should have already (cssnano spring to mind here).

In fact we should be encouraging people to use their own pipelines, but by keeping this tool around we can quickly move the dev tools of all the packages over to postcss and provide a simple way to build the project if people need it.

Using cssnext directly doesn't offer much as it uses multiple plugins anyway, and from what I understand it is soon to become just a postcss plugin itself - MoOx/postcss-cssnext#230

Would make sense to manage the package from one single build tool. We could then deprecate/remove rework-suit and rework-suit-conformance

Here's our discussion from yesterday - https://gitter.im/suitcss/suit?at=564902c58b242470793dea82

But i think I'm sold on the refactor route

from preprocessor.

@simonsmith @giuseppeg glad you guys discussed this, I've been leaning in this direction as well.

Could a possible tradeoff be to maintain all the docs and tooling in the main SUIT repo, and have each package have the main repo as a dependency?

from preprocessor.