Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion 1.0 release #29

Open
joshgillies opened this issue Aug 19, 2015 · 15 comments
Open

Discussion 1.0 release #29

joshgillies opened this issue Aug 19, 2015 · 15 comments
Milestone

Comments

@joshgillies
Copy link
Member

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.

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
Copy link
Member

joshwnj commented Aug 20, 2015

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
Copy link
Member

joshwnj commented Aug 20, 2015

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
Copy link
Contributor

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
Copy link
Member Author

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?

@joshwnj joshwnj mentioned this issue Aug 20, 2015
@geelen
Copy link
Member

geelen commented Aug 20, 2015

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
Copy link
Member

joshwnj commented Aug 20, 2015

Let's go straight to css-modules-2015

@mightyaleksey
Copy link
Member

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
Copy link

+1

@joshwnj joshwnj added this to the 1.0 release milestone Aug 25, 2015
@joshwnj
Copy link
Member

joshwnj commented Aug 27, 2015

@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
Copy link
Member

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

@rtsao
Copy link
Contributor

rtsao commented Aug 31, 2015

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.

@joshwnj
Copy link
Member

joshwnj commented Aug 31, 2015

good idea @rtsao. I've added #38 to the v1.0 milestone.

@royriojas
Copy link

hey guys, very nice module, what about to provide a wrapper function over the exported classes?

Current version

var styles = require('./path/to.css');

styles.field // might be undefined but no error is thrown, instead undefined might be interpolated if this is added to a string

I would prefer something like

var cssModule = require('./path/to.css');
cssModule.k('field') // will throw if the class field is not found, will return the renamed class if original class found

This problem is mentioned here

And I have also made an implementation for something similar on this experimental transform that I use to compile less files to css and inject it to the document as styles tags

@mightyaleksey
Copy link
Member

@royriojas Am I right that you want to solve possible problems with typos?

@royriojas
Copy link

@sullenor yes! I had too many of them, that's why I made that small function. It is better an error than an "undefined" class added to the elemets

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants