search

jstransformers / jstransformer

Normalize the API of any JSTransformer.
http://npm.im/jstransformer
MIT License
152 stars 12 forks source link

Implement missing transformers #1

Closed ForbesLindesay closed 9 years ago

ForbesLindesay commented 9 years ago

This project aims to replace transformers with a large collection of separate libraries, each of which able to be separately maintained, tested and updated. Each library will implement some subset of the API in this module, and may optionally return a string body rather than the {body: String, dependencies: Array.<String>} format (lots of file formats don't actually have dependencies so it wouldn't really make sense). This module can then be used to fully normalise that interface, including implementing the methods that are otherwise not implemented.

Here is a list of all the modules that need implementing

Once all of these have been implemented, we can switch jade to look for these rather than transformers. I'll need as many collaborators as possible for this, so if you're willing to contribute a transformer, let me know and I'll add you to the organisation. P.S. note that we add jstransformer to the keywords in package.json for all transformers, so they can be found at https://www.npmjs.com/browse/keyword/jstransformer

RobLoach commented 9 years ago

:sparkles: https://github.com/jstransformers/jstransformer-browserify :sparkles:

Plugins

I think it should take an options.plugins parameter, and process it accordingly in preparing .compile/.render. Having to build a Transformer for each plugin is a lot of maintenance work for us, and limits the abilities of what the transformer can do.

As a side note, we'll need this plugins pattern for Browserify too. Made an issue: https://github.com/jstransformers/jstransformer-browserify/issues/2

RobLoach commented 9 years ago

@jstransformers/owners First pass on https://github.com/jstransformers/jstransformer-cli .... Let's get discussions going on over in the issue queue there.

tunnckoCore commented 9 years ago

Having to build a Transformer for each plugin is a lot of maintenance work for us, and limits the abilities of what the transformer can do.

i'll repeat again, there's no bad side of this. it not limit what jstransformer can/will do. and no, no "more work for us" when the pkg have quality and good tests, plus I'm very active every single day.

ForbesLindesay commented 9 years ago

@tunnckoCore The thing is that maintaining those is out of scope for jstransformers. It is crucial to the success of any organisation that it remain focused. There are three reasons this is really important:

  1. There is another, much better way for us to support this, via a simple "plugins" option. This is idiomatic of how jstransformers are generally expected to work (see jstransformer-less for example).
  2. By forcing each plugin to be a separate jstransformer, we make some functionality impossible. For plugins that take x -> y rather than x -> x you can't always break things up in the way you want to. Consider, for example, browserify transforms. You have to give all the transforms you want to the same, single, browserify instance. You simply cannot do it in multiple passes.
  3. Doing multiple passes can create a massive performance bottleneck. Say I want to use cssnext and doiuse from postcss: if I use the plugins system, it parses the css once, applies two transformations to the AST, then outputs that AST to a string. If I use your approach, I have to parse the AST and then stringify it for each plugin I want to make use of. That performance bottleneck is our problem, not the problem of postcss.
tunnckoCore commented 9 years ago

@ForbesLindesay It seems you dont understand me correct. Im not against plugins option and i'll implement it in postcss. The idea is to support separate jstransformers only for some of postcss plugins which walk their way to the future as separate tools. It would be more clean and lean to use just jstransformer-cssnext, not using plugins option for only one plugin.

Choosing to use separate jstransformers in this way, when we have support for both ways would be idiotism, yea. And this would be user's implementation/architecture design mistake, not our problem - we all have heads on our arms to think. I just won't support users that cant think, that dont have some principles and at least little basic knowledge about "what and how", that dont have logical/rational mind.

Regards, Charlike. :)

tunnckoCore commented 9 years ago

Its looks better

var transformer = cssnext.renderFile('path/to/foo/bar.css', {})

// instead of
var transformer = postcss.renderFile('path/to/foo/bar.css', {plugins: [cssnext()]})
tunnckoCore commented 9 years ago

resin done, but i didn't notice that the resin package is out-of-date and they move to topcoat-resin and republish, soo yea shitty shits.

postcss and rework now support options.plugins.

RobLoach commented 9 years ago
RobLoach commented 9 years ago

@tunnckoCore found https://github.com/stylecow/stylecow

tunnckoCore commented 9 years ago

@RobLoach haha, you're good follower! :cat2:

hemanth commented 9 years ago

We still have few left in the potential extras list.

RobLoach commented 9 years ago

I've created a Label for this, and added each Transformer as an issue so that we can track them individually: https://github.com/jstransformers/jstransformer/issues?q=is%3Aopen+is%3Aissue+label%3ATransformer

Considering all of our projected initial requirements are met, I'll close this now that we have the other issues open. Great work, guys!

ForbesLindesay commented 9 years ago

:+1: awesome work.

Thanks so much for supporting this project everyone. I'm so excited for how big this is becoming.