Split project

[ai]

I thinking of splitting project to:

• postcss-ast with nodes classes.
• postcss-css with default parser.
• postcss-plugin with API for plugins.
• postcss-utils with vendor and list.
• postcss-process with Result, Processor, etc.
• postcss-map with source map support.

Of course, just postcss wwill contain all of them with same API.

As result:

• Custom parsers dependencies will became simplier.
• We will be able to make very tiny build of PostCSS for client side (like React Styles). Now source-map library is too big.

[MoOx]

It’s a good idea to split packages on npm, but you should keep all the code base in the same repo, in order to make maintenance more easy. Rework split in the past and it was a pain to update all packages…
Babel is also having multiple packages, but all code in in one repo.

[lydell]

@MoOx Good idea about keeping it all in the same repo. That should not introduce the problems rework had.

[ai]

The only project with one repo is using master in package.json, but it is not so important.

Small note: ouh, I am soo miss Bundler in node.js. GitHub master cases were so easy there. One repo with many projects is not a problem for it.

[ai]

First tests show that we can reduce core for client-side from 30 KB to 10 KB.

[yisibl]

Good idea!

[yoshuawuyts]

Ideally I'd prefer an arbitrary function syntax for plugins without the need to pull in a package, e.g.

module.exports = function () {
  return function (style) {
    // traverse & modify style
  }
}

This would make it easier to intererop with other CSS bundlers, such as sheetify. ✨

[ai]

@yoshuawuyts first version of PostCSS has simple function API too, but here is a reason why we use more complicted way. If you can fix them in different way, we can change API:

1. PostCSS versions conflict, when you use pllugin for PostCSS 4.x with PostCSS 5.x core. We can use npm peerDependency, but in most cases major update is fine. So current way show warnings if conflicted plugin has error, but it still allow you to run old plugins.
2. Automatically insert plugin name to warnings and errors.
3. Allow to fix plugins possible conflicts. Because every plugin has plugin.postcssPlugin with name, other plugin can check result.processor.plugins and warn user on problems. Or cssnano plugin pack disable internal Autoprefixer if it see, that it is already used.

[yoshuawuyts]

ah, yeah 2 + 3 make a lot of sense. Perhaps an api that looks like this could work for this case:

module.exports = function (meta) {
  meta({ name: 'rebecca-purple' })
  return function (style) {
    // traverse & modify style
  }
}

or

module.exports = function (css) {
  css('rebecca-purple', function (style} {
    // traverse & modify style
  })
}

[ai]

In 6.0 postcss-plugin will be very small, just one file for 10 lines of code. But it will also fix first problem and have old API.

@yoshuawuyts Why you do not like this solution?

[yoshuawuyts]

Actually that sounds great, happy to see that happen ^^