Clarify config

[peteruithoven]

The readme mentions that it's possible to add configuration for this plugin:

    // additional config can also be set through `builder.config`
    builder.config({
      separateCSS: true,
      rootURL: './public'

      // to disable css optimizations
      // cssOptimize: false
    });

Is this also possible without a custom builder script, using the jspm cli?
Is it possible to add this to the jspm.config.js file?

// additional config can also be set through builder.config

I don't understand what this means. I've searched in docs of plugin-css, Builder and jspm-cli. Does this refer to the --config option? This is also mentioned on the following page:
http://jspm.io/0.17-beta-guide/custom-package-resolutions.html
Can the above mentioned options be added to the top level or should they be in another object, like cssOptions for example?

[guybedford]

These options should have been namespaced under a cssOptions really. But yes, this is top-level loader configuration, which isn't be supported as of SystemJS 0.20. Strictly this project should be moving to a meta approach or another method to continue to support these properties.

[ffflabs]

@peteruithoven @guybedford

when translating the source, css-plugin-base calls its CompileCss function parameter as

compileCSS.call(loader, load.source, load.address, load.metadata.loaderOptions || {})

See css-plugin-base.js#L17

Which means, for example, that you must pass the config options namespaced as loaderOptions in jspm.config.js:

"meta": {
   "*.css": {
        "defaultExtension": false,
        "loader": "css",
        "loaderOptions": {
          "cssOptimize": false
        }
    }
}

However...

The compileCSS function passed in css.js#100 is

function compile(source, address) {
        return {
          css: source,
          map: null,
          moduleSource: null,
          moduleFormat: null
        };
      }

So the third parameter will always be empty, meaning your options won't ever be passed to css-plugin-base when translate gets called.

However, then css-plugin-base.js calls its bundle method, it actually calls the bundle method of css-plugin-base-builder.js which can be albeit hacky configured with root properties of SystemJS.config.

Setting properties:

• baseURL
• browserRootURL
• cssNano
• inlineCssSourceMaps
• rootURL
• separateCSS

does influence the behavior of the bundling.

It's still weird that you can only influence the behavior of the bundling with root properties,

[guybedford]

@amenadiel I see your point about these inconsistencies. I don't personally have the time to continue developing this project apart from simple review and release management, but if anyone is interested in moving this project forward a new collaborator would be really welcome.

[ffflabs]

@guybedford I'd love to, but my current working schedule has me in the workplaces nearly 70hrs a week (with no extra time payment due to my position). So while writing this I'm purposely procastinating the resolution of a bug I have to repair today.

When I get some spare time I usually devote it to my own personal open source projects that in turn have their own issues and zero contributors, eventhough I created and organization for them and added every developer friend I have to see if they lend a hand. To no avail.