Support PostCSS processor

[iamvdo]

You really should add a public interface that can be used in PostCSS's use() function. For example:

    var processed = postcss().use(
      autoprefixer.postcss
    ).use(
      rtlcss.process
    ).process(css);

See differences between node-css-mqpacker 0.0.2 and 0.0.3

[MohammadYounes]

Thanks, I'll check it out.

[am11]

@MohammadYounes, going by this feature request of yours.

We have autoprefixer web service in WE, which currently supports:

• Call from other services: LESS and SASS. If the source-maps were generated with output of LESS or SASS, autoprefixer updates those generated source-maps as well.
• Call independently. The functionality is there, but we aren't using it in WE yet as we don't have autoprefix support for vanilla CSS files (only those which generated from LESS or SASS). Also, WE doesn't support source-maps for minified CSS yet (only min JS).

Now, I think we can alter autoprefixer in a way that it can support rtl conversion, using the chained syntax (as opposed to add it as a separate service).

Points to ponder:

• Does using autoprefixer with rtlcss means it will take care of source maps? Have you tested V3 source-maps scenarios?
• If it does, then rtl can work with WE for LESS and SASS in a way that it will allow us to generate both rtl and ltr CSS variants as well as take care of the source-maps. In this situation, what kind of UI do you propose for rtl generation to integrate in the existing feature?
• Finally, we would have to first enable autoprefixing for vanilla CSS in WE, then rtl can be provisioned. But I am not exactly sure how the first one should work: generate separate file for prefixed output, update the CSS file inplace (source = target), provide menu item to update, prefix on save etc.

Note: to get the latest experience of WE, update to VS2013 Upate 3 and WE 2.2.7 nightly. v2.3 stable is on its way; ComingSoon™ :)

[MohammadYounes]

@am11 Please ignore my previous response, I found a bug in what I wrote before (now fixed).

Regarding source maps, rtlcss acts the same as autoprefixer (both delegate such functionality to postcss).

It makes great sense to chain rtlcss in rtl only builds. But for builds that need to have both ltr/rtl variations, the chaining becomes invalid. because it outputs a flipped version of the provided input (as opposed to adding browser prefixes), So I believe it should be in a separate service or its output returned in a different variable. ( I like to think of rtlcss as a branch created just before minification takes place )

As for the UI, Since rtlcss supports adding your own custom processing instructions, I think having a configuration file is the way to go:

A Default RTLCSS-Config.json :

{
    "options": {
        "preserveComments": true,
        "preserveDirectives": false,
        "swapLeftRightInUrl": true,
        "swapLtrRtlInUrl": true,
        "swapWestEastInUrl": true,
        "autoRename": true,
        "greedy": false,
        "enableLogging": false,
        "minify": false
    },
    "rules": [ ],
    "declarations": [ ],
    "properties": [ ]
}

On RTLing, WE should read the config file and pass the parameters to rtlcss:

var result = rtlcss(config.options, config.rules, config.declarations, config.properties).process(css, { from: 'ltr.css', to:'rtl.css', map:  true, prev ... });

result.css // => rtl css ... 
result.map // => {"version":3,"sources":"ltr.css"],"names":],"mappings":"GAAG;YACS,eAAc;YACd,kBAAiB ....

If no config file specified, rtlcss will work with the default options:

var result = rtlcss().process(css, { from: 'ltr.css', to:'rtl.css', map:  true, prev ... });

A final thought on enabling rtlcss on vanilla css files, I think having a menu item similar to "Minify file(s)" option. and the output file to be {filename}.rtl.css

I can't wait for this to be a feature of WE, and I am happy to make any required changes that would help push this forward.

[am11]

@MohammadYounes, thanks for the details.

I am bit busy with other stuff at the moment, I will dig deeper at later point.

For the config file settings, I think its a bad idea. The way how other linters and compilers work is they locate the config file first in the current directory of input file (not process.cwd), then find-up (there is an npm called find-up with tslint is using) until it hits the drive root. After that it looks into home directory.

As a rescue, in Web Essentials, we check and copy a default one from our cache to home directory before every lint command.

References:

• JsHint: https://github.com/jshint/jshint/blob/64417517101399c03d78173a2c90e3f24e81de58/src/cli.js#L74-L107
• JSCS: https://github.com/mdevils/node-jscs/blob/180baa19b983fd9d9f5c6793b0d6383674824ce7/lib/cli-config.js#L16-L41
• CoffeeLint: https://github.com/clutchski/coffeelint/blob/5ae14256cae520f8da566fcfb9f63ccb3fff4e38/src/configfinder.coffee#L14-L24
• TSLint: https://github.com/palantir/tslint/blob/d4f3f97515880da678e0f0c606341c3b8e4ac646/src/configuration.ts#L24-L52

And this is WE's recue code: https://github.com/madskristensen/WebEssentials2013/blob/759ea1261cfef0a2abd6bbcefc2590c9a8dbf0ba/EditorExtensions/JavaScript/Linters/JsHintCompiler.cs#L30-L42

Please implement this configuration lookup. Thanks.