-
Notifications
You must be signed in to change notification settings - Fork 47
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
Comments
On one hand I wonder if it makes sense for I guess it mainly means that when |
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. |
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! |
Oh yeah I don't think we need to wait on |
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 |
Let's go straight to css-modules-2015 |
Do you mind if we add some information about |
+1 |
@sullenor I've mentioned Are there more things you think should be said about it? |
@joshwnj I like yours detailed description and I think it is sufficient to understand the subject. Thank you! |
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. |
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 |
@royriojas Am I right that you want to solve possible problems with typos? |
@sullenor yes! I had too many of them, that's why I made that small function. It is better an error than an |
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! 😄
The text was updated successfully, but these errors were encountered: