Electron Support

[knpwrs]

What would you guys think about a pull request to support Electron? My basic idea would be to detect if window.document.head exists and if it does exist to inject the styles into the head. Probably somewhere around here...

[geelen]

OOOOOOHHHHHH this is a good idea! I would maybe make it a new project though. I want to build up a list of "If you're building for this environment, use this project" and so having NodeJS and Electron both in the list with their own project names and own readmes would be good.

Of course, they'd probably share 99% of the code. But then at least there's no environment-guessing going on, so the code for each project becomes simpler.

Thoughts?

[knpwrs]

I like that. The Electron version would probably also support source maps and other things to the point where it might diverge from this project enough anyway. I'll put something together over the next few days.

[mightyaleksey]

I thought about adding another option, which will add opportunity to handle the final CSS. So the user will be able to specify a custom function, which can inject styles into the DOM or do any other stuff.
I'm not sure about the design, but I think it is a simple solution. For example,

var hook = require('css-modules-require-hook`);
hook({
  processCSS: function (cssString) {
    /* code, which injects the styles into the head */
  }
});

I also like the idea of separated versions for specific environment.

[mightyaleksey]

I also think about making a public version of the postcss-parser-plugin, which is used as an endpoint to export tokens and styles (currently tokens only), so it will be easier to build other tools.

What you think about it?

[knpwrs]

@sullenor I like both of those ideas. If you were to add a processCSS option then whatever I end up implementing could be a simple wrapper around this module (though my inner camelCase nazi would prefer processCss to processCSS). Also, breaking out postcss-parser-plugin into its own module would enable more flexibility for the future.

[mightyaleksey]

@kenpowers I thought that abbreviation should be written in the uppercase, cause its a set of words :)
But I don't mind to add a variant of yours.

Anyways, I published the new release. You may try to use it.

[knpwrs]

Cool, I'll give it a go some time this weekend.

As for camelCasing, my convention comes from my desire to keep my cases non-destructively convertible through libraries. Take, for example, Lodash:

var s1 = 'processCss';
s1 = _.kebabCase(s1); // 'process-css'
s1 = _.camelCase(s1); // 'processCss'

var s2 = 'processCSS';
s2 = _.kebabCase(s2); // 'process-css'
s2 = _.camelCase(s2); // 'processCss'

My most recent use for converting cases was for handling webhook events from GitHub. They send event names in snake_case and I needed to map those to appropriate JavaScript functions in camelCase. Then, of course, there's HTML5 data attributes which automatically convert from kebab-case to camelCase.

Obviously these use cases don't even apply here, so it doesn't really even matter. But I'm a sucker for consistency. 😄

[mightyaleksey]

:D

[knpwrs]

I got a working example going. Turns out I also had to rewrite URLs in the CSS (which makes sense, since URLs are relative to the files). I just have to build out the API a little bit to let people specify options.

So I know css-modules-loader-core is a thing, but I think it might be handy to have the core set of PostCSS plugins available somewhere as an array. For example, the following from css-modules-electron:

  use: [
    // Core css-modules plugins
    require('postcss-modules-extract-imports'),
    require('postcss-modules-local-by-default'),
    require('postcss-modules-scope'),
    // Rewrite css urls
    require('postcss-url')({
      url: function (url, decl, from, dirname, to, options, result) {
        return path.join(root, dirname, url);
      }
    }),
  ],

Could be:

  use: core.concat([
    // Rewrite css urls
    require('postcss-url')({
      url: function (url, decl, from, dirname, to, options, result) {
        return path.join(root, dirname, url);
      }
    }),
  ]),

Or maybe there could be some other more friendly way to plug in additional PostCSS plugins without having to specify the core plugins again. Unless I'm missing something from the already available API here.

[knpwrs]

I just pushed a change that lets users specify plugins to use before and after the core plugins. Essentially the revelant code is:

export default function(pre = [], post = []) {
// ...
    use: [
      // Pre-plugins
      ...pre,
      // Core css-modules plugins
      require('postcss-modules-extract-imports'),
      require('postcss-modules-local-by-default'),
      require('postcss-modules-scope'),
      // Rewrite css urls
      require('postcss-url')({
        url: function (url, decl, from, dirname, to, options, result) {
          return path.join(root, dirname, url);
        }
      }),
      // Post-plugins
      ...post
    ]
//...
}

Thoughts?

[mightyaleksey]

Yeah, just saw your code, good work!

I like the idea of using pre|post options for the short way to add additional plugins, but I'm afraid of ending with numerous options and difficulties from choosing particular options for the resulting list.

For example, if you want to provide custom options to the core plugins, you have to build an instance of the plugin first and provide it explicitly.

hook({
  use: [
    new require('postcss-modules-extract-imports')({ /* custom options */ }),
    ...
  ]
});

Also, I lack ability to provide global options to the lazyResult instance. It can be necessary for another plugins, like postcss-url.

So, I'm afraid that it will be difficult to set up the require hook in the end.

[mightyaleksey]

I think about changing a way of configuring the require hook. I want to replace object with parameters by particular methods. So you will be able to export necessary methods and use them.

It is idea only, but I'm not sure if it will be good :)

[knpwrs]

Something like...

var hook = require('css-modules-require-hook');
hook.use(...);
hook.register();

?

[mightyaleksey]

kind of