jstransformers / jstransformer Goto Github PK

@tunnckoCore brought this up in https://github.com/jstransformers/meta/issues/2 .

I believe a large chunk of these tools will be handled by https://github.com/jstransformers/nuke or whatever we end up adding in there.

https://github.com/mailru/fest

https://www.npmjs.com/package/hamljs

We've got haml, but not hamljs.

http://the-echoplex.net/csscrush/

https://github.com/hemanth/css-longhand

In transformers, 'xml' is used, even for HTML output.

In the first few packages ported by @ForbesLindesay, they are marked as 'html'.

In my first few packages, I used 'html' as well, but then I saw that transformers was using 'xml', so I switched to 'xml'.

What exactly should I use?

What about hybrids like XHTML/XML: https://github.com/jstransformers/jstransformer-cdata?

When the transformer doesn't have .compile(), but does have .render(), jstransformer.compile() could create it.....

Transformer.prototype.compile = function (str, options) {
  if (!this.can('compile')) {
    // Fall back to tr.render(), if it's available.
    if (this.can('render')) {
      var _this = this;
      return tr.normalizeFn(function (locals) {
        return _this._tr.render(str, options, locals);
      });
    }

https://github.com/dominictarr/hyperscript

http://leonidas.github.io/transparency/

We have outputFormat to define what the outcome of the tranformer is. Should we also define an inputFormat to say what the input for the transformer usually is?

SCSS could become scss, defaulting from the exports.name.

While Remarkable, Marked, Markdown, etc would define:

exports.inputFormats = ['md', 'markdown'];

https://github.com/anandthakker/doiuse

https://github.com/cssnext/cssnext

https://www.npmjs.com/package/string-template

https://github.com/jsstyles/jss

https://github.com/borgar/textile-js/

@stoeffel asked in https://github.com/jstransformers/meta/issues/3

What do you think about creating a generator-jstransformer for yeoman, to simplify the process of creating new jstransformers?

@hemanth replied

Well, at the rate at which the modules are being churned, we will exhaust our todo list soon, but anyway it would be any harm to have a generator 😄
BTW, if you haven't noticed yet, there is a bolierplate.

https://github.com/mikesmullin/coffee-stylesheets

For example currently compileFileAsync does this:

1. check and use compileFileAsync
2. check and use compileFile, which must use sync readFile
3. check and use compileAsync, wrapping it around async readFile
4. check and use compile, wrapping it around async readFile

Say I supply a synchronous compileFile, compileFileAsync is basically forced to use synchronous file IO, which might be suboptimal.

I propose a compileFileCommon function that handles the stuff common to both functions when compile is synchronous, and jstransformer automatically adding the file I/O operations.

Same goes for compileClient and compileClientAsync.

https://github.com/slm-lang/slm

https://github.com/mikesmullin/coffee-templates

The centered logo distracts the user from the documentation, which is more important. Also looks weird on npm: https://www.npmjs.com/package/jstransformer

Let's do what Promises does for their logo:

https://github.com/then/promise

https://github.com/aeosynth/ccss

https://github.com/AriaMinaei/RenderKid

https://github.com/medikoo/domjs

I.e. what each function takes in and can return.

We should discuss the licensing/copyright issue. At the moment everything is consistently MIT. That's great and I see no reason to change that. It does, however seem a bit odd to have the copyright assigned to individual people for individual repos. Especially as with the project ultimately maturing, many of the modules may end up being primarily maintained by someone who didn't initially create them.

Could we assign copyright to "jstransformers" as an organisation? Are there any legal issues? Does anyone have any other objections?

https://github.com/jonschlinkert/template

wazza :)

xml2js have only async, soo.. i should implement only .renderAsync, right? But when implement it like

exports.renderAsync = function _renderAsync(str, opts, locals, callback) {
  xml2js.parseString(str, opts, callback);
};

then when try it

var transform = require('jstransformer')(require('../index'));
transform.renderAsync(fixture, {}, {}, function(err, res) {
  console.log(err, res)
});

or like

var transform = require('jstransformer')(require('../index'));
var promise = transform.renderAsync(fixture);
// throws error to .catch

it throws [Error: Invalid result object from transform.] in both cases

https://github.com/suitcss/preprocessor

https://github.com/kof/jqtpl

I dont know why, but for some reason it fails to populate template with given locals in some template engines like handlebars and I guess other was toffee. check this and this, its not logical to fail, because other render* methods works correctly.

For that reason Im so strong with my position to use jstransformer for testing it helps to find bugs like this, have more useful use cases which in other hand in one point is useful as examples.

https://github.com/pure/pure

https://github.com/elm-lang

Okey guys, some points. Inspiration jstransformers/jstransformer-liquor#1 and tests like that

Please, lets come to that to use jstransformer for all the modules. It will be just in devDeps, so I dont see the problem.

Current testing flow is awful for me. Tests should be descriptive, should be as an examples, should test some more real use-cases (I mean, more than just hello {{name}}) or template engine specifics, also should have descriptive descriptions.
Tests should be like these.

What is that "Mote.js" description (mentioning jstransformer-mote test)? - Nothing.
You even set transform.name as test description in our generator.

Using testit for just one simple line saying "mote.js" or "liquor" to the stdout, whaa?!

Tests like this dont have meaning for me. They told me nothing, what remains to users?

I also dont like very much assert.equal, so assertit.equal is assert's strictEqual

assertit is enhancement, thin layer on top of testit and assert - read it's tests to see the actual usage.

@ForbesLindesay @RobLoach i think it should be text not exactly html as now in mustache transformer

https://github.com/tunnckoCore/j140

I see lots of use of strings, but haven't seen much implementation surrounding Streams. Any thoughts?

https://github.com/raycmorgan/Mu

https://github.com/adammark/Markup.js

https://github.com/xudafeng/microtemplate

Rather than returning the {dependencies, body} for .render() and .renderFile(), have it return a Promise?

Or switch over to Generators and yield for everything?

https://github.com/MohammadYounes/rtlcss

Now that there are a good amount of Transformers available from #1, it is time to think about what the next steps are for JS Transformers' success. So, what is missing?

• Add an API to jstransformer that is rather similar to the existing implementation?
• Push a project page forwards to http://jstransformers.github.io ?
• Add API docs on the .compile function for templates?
• Create plugins for other systems that could use JS Transformers?
• Publish jstransformer on npm?

I put together a Metalsmith plugin to use JSTransformer, and thought it would be a good idea to have a list of potential ideas for other integration points with external systems to help encourage collaboration. Feel free to edit this list and add any other ideas.

• Jade - Put together a Jade filter
• Metalsmith - metalsmith-jstransformer
• Grunt - Plugin to process files through JSTransformers
• Gulp - Plugin to process streams through JSTransformers http://github.com/jstransformers/gulp-jstransformer
• Duo - plugin for DuoJS
• koa ?
• connect ?
• DocPad - Plugin to process files with JSTransformers
• browserify - plugin to inline the results of calls to jstransformer methods where the args are constants
  Should some of these live in the jstransformers org? I could move metalsmith in.
• PHP Port - PHPTransformers
• Webpack jstransformer-loader
• Fly Build System
• Cha task chaining
• start task
• rollup plugin

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

• coffeecup
• coffeekup
• haml-coffee
• jazz
• jqtpl
• just
• mote
• qejs
• templayed
• walrus
• whiskers
• atpl
• dot
• dust
• haml
• handlebars
• liquor -- done but unusable and not published because of chjj/liquor#5
• markdown-js
• toffee
• cdata
• cdata-css
• cdata-js
• coffee-script
• cson
• eco
• ect
• ejs
• escape-html
• highlight.js
• hogan
• jade
• less
• livescript
• markdown
• markdown-it
• marked
• mustache
• plates
• remarkable
• sass
• scss
• stylus
• supermarked
• swig
• uglify-css -> rename this to "clean-css" and use the clean-css module
• uglify-js
• uglify-json -> rename this to just "json"
• underscore
• verbatim

Potential Extras

• JsRender
• Marko
• CSS Longhand
• autoprefixer built with postcss
• coffee-stylesheets
• cssnext built with postcss
• doiuse built with postcss
• fest xml to html transformation
• gaikan
• hyperscript
• j140
• stylecow
• String-Template
• Duo.js
• Coffee React
• octet
• renderkid
• rtlcss built with postcss
• slm-lang jade-like template engine for node and browser
• svgo Nodejs-based tool for optimizing SVG vector graphics files
• ccss bugs, need PRs there
• coffee-templates tricky shit, atm
• absurdjs
• babel
• browserify
• es6-template-strings
• gray-matter
• ini
• jsx
• lodash
• mini-handlebars
• myth
• postcss
• resin built with rework
• rework
• toml
• webpack
• xml2js
• styl
• jscss bugs, need PRs there

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

https://github.com/constantology/Templ8

https://github.com/jsdf/coffee-react

Also the names of properties.. We need more consistency.

Proposal

• outputFormats alias to outputFormat
• inputFormats alias to inputFormat
• both to accept only arrays (or plural array, singular only string?)

Why?

1. Because libs like AbsurdJS can output css and html, not in same time, but yea. It can transform from JSON/YAML/CSS/JS to CSS/HTML.
2. fast-fingers mistakes, one is plural, other is singular.. nah, not good.

exports.name = 'absurd';
exports.inputFormats = ['absurd', 'absurdjs', 'js', 'json', 'yaml', 'css'];
exports.outputFormats = ['css', 'html'];