Discussion 1.0 release

[joshgillies]

Ok I think it's time we start a little shopping list of features we'd like to see in the 1.0 release of css-modulesify. Given the press CSS Modules are getting at present we should aim to keep this project inline what the JSPM and WebPack implementations offer, whilst leveraging what Browserify offers it's uses as best we can.

At present there's a few issues currently outstanding which contain feature requests and discussion around improvements to the css-modulesify architecture.

• Other ways to add postcss plugins #26
• feature request: ability to get output as a stream #17
• support pre-proccessors like LESS or SASS #14

If there's anything more people would like to see in this project, please feel free to file an issue. Just remember to ping this one so we can keep things in line.

/ping @joshwnj @joeybaker would love your input here! 😄

[joshwnj]

On one hand I wonder if it makes sense for css-modulesify to go to 1.0 before css-modules-loader-core does? Since there may still be changes there.

I guess it mainly means that when css-modules-loader-core goes 1.0 we may need to bump to 2.0 (if there are breaking changes). Which is fine - the numbers don't need to mean anything in themselves.

[joshwnj]

One thing I definitely want to nail before we go 1.0 is a solid workflow for hot reloading, since this is something that might require some changes to css-modulesify.

[joeybaker]

A thing I've noticed but haven't had time to investigate: css-modulesify outputs no css on subsequent builds with https://github.com/bjoerge/rebundler. I suspect this is because css files aren't being added to the browserify cache because they're required by a custom loader. I'd like to get this fixed for a 1.0 but won't have the time to look at it for several weeks.

Aside from that, @joshwnj, your list looks good!

[joshgillies]

Oh yeah I don't think we need to wait on css-modules-loader-core to push to 1.0. Personally I'd like to take a critical look at the plugins architecture, possibly re-do it all together. Also, potentially de-couple css-modulesify CLI for the core API. Anyway, @joshwnj care to file an issue regarding hot-loading & @joeybaker same with the bug relating to rebundler?

[geelen]

I reckon I'm gonna bump loader core to 1.0 real soon anyway, I think we have enough momentum that the spec is feeling pretty solid, and I non-backwards-compatible changes would merit a v2.0 anyway.

[joshwnj]

Let's go straight to css-modules-2015

[mightyaleksey]

Do you mind if we add some information about rootDir option to the readme file? I think it's vital to mention it in order to have same class names with require-hook.

[serapath]

+1

[joshwnj]

@sullenor I've mentioned rootDir here: https://github.com/css-modules/css-modulesify/#using-css-modules-on-the-backend

Are there more things you think should be said about it?

[mightyaleksey]

@joshwnj I like yours detailed description and I think it is sufficient to understand the subject. Thank you!

[rtsao]

IMHO dead code elimination should be a feature for 1.0: css-modules/css-modules-loader-core#13

It seems to me that lack of dead code elimination is a barrier for production use of css-modules. For example, if a single class is composed from a css file containing 100 classes, all 99 unused classes are included.