Split project #503

Open
ai opened this Issue Aug 21, 2015 · 10 comments

Projects

None yet

5 participants

@ai
Member
ai commented Aug 21, 2015

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.
@ai ai added the question label Aug 21, 2015
@ai ai changed the title from Split projects to Split project Aug 21, 2015
@MoOx
Member
MoOx commented Aug 21, 2015

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
Contributor
lydell commented Aug 21, 2015

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

@ai
Member
ai commented Aug 21, 2015

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
Member
ai commented Aug 22, 2015

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

@yisibl
Contributor
yisibl commented Sep 6, 2015

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
Member
ai commented Sep 13, 2015

@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
Member
ai commented Sep 13, 2015

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 ^^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment