using css modules with gulp-babel

[radubrehar]

I know this is not so much a matter of css loader/modules, but I really don't know a better place for this question.

My problem is I have React components, and like having a folder for each component, with all required resources (jsx, css, images). For example

var ClassName = require('./index.css')
var Footer = React.createClass({
   render(){
     return <div className={ClassName.footer}>
       {this.props.children}
     </div>
   }
})

My problem is I want to use gulp-babel to transpile all my app to normal js, and keep folder structure, etc. ( I would like to use webpack, but as far as I know, it cannot be used for this), so transform /src folder to /lib folder.
So people using my component, especially in webpack/browserify wil be able to use it (in package.json I have "main": "lib/index.js") so, if they use lodash or other modules in their app (and it happens my component also uses them), they get the module they are using, not the one my component is enforcing.
Basically, I want to avoid having to distribute a minified/concatenated version of my component.

But since gulp-babel only does transpilation, it will leave require('./index.css') as is, which is not what I want. What I really want is to remove those css requires (probably before transpilation) from the transpiled sources (people will be including an external css file the component is providing).

Any ideas on how to accomplish that? Thanks

[bebraw]

There's likely no simple way to remove actual require statements within Webpack. You would have to use a transformation tool like recast for that.

Perhaps a nicer way to solve this would be to resolve CSS against null-loader? In this case the require statements would be included but they simply would do nothing.

[radubrehar]

Well, replacing the css-loader with the null-loader would not solve the problem, since I use the value returned by the css require call since I have auto-generated classNames.

[joshwnj]

@radubrehar I wonder if what you need here is a new babel plugin? The main work of the plugin (exporting locally-scoped classnames) can be done with https://github.com/css-modules/css-modules-loader-core, like what we've done with https://github.com/css-modules/css-modulesify

There is a somewhat-related conversation going on over at css-modules/css-modules#13 if you're interested.

[radubrehar]

Yes, I think a babel plugin is what I need. It should replace the css require call with an object containing the names of the auto-generated classes. The resulted code should be commonjs/nodejs compliant, so it can be used by third parties.
Thanks for pointing out to those links. I still don't think they solve the problem completely but it's a start.

Thinking more thoroughly, I think we need more than a babel plugin, since we need it to be aware of the classNames generated by webpack at build time (when the css bundle is built), so we might need a more tight integration.
What do you think?

[joshwnj]

You're right, there will be a little more work required to get css-modules-loader-core exporting identical classNames (at babel-time) to webpack (at build-time), because the format may be slightly different.

From what I can tell, you'll need to match webpack's localIdentName to postcss-local-scope's generateScopedName, which can be customized in an option: https://github.com/css-modules/postcss-modules-scope/blob/master/src/index.js#L33

You can see an example of this here: https://github.com/css-modules/css-modulesify/blob/master/index.js#L9-L19

[aluxian]

I also use webpack with babel, also SASS and I think I found a solution to this: I forked css-loader and added a new parameter for localIdentName: sourceHash. This generate a hash from the localName and the source code, so the class names are stable.

https://github.com/Aluxian/css-loader

[istarkov]

Looks like I just released babel 6 plugin for webpack loaders so you can build your library with babel as babel src --out-dir lib

[radubrehar]

Well ... this is HUGE! This looks fantastic to me! Thanks a lot

[radubrehar]

I think this should solve this issue. Other impressions?

[joshwiens]

I am resolving this issue. To the original issue, all support requests / questions should be done in either the Webpack Gitter or in Stack Overflow w/ the webpack tag