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

Variable map is always overwritten by local vars #38

Open
aaronj1335 opened this issue Sep 9, 2014 · 3 comments
Open

Variable map is always overwritten by local vars #38

aaronj1335 opened this issue Sep 9, 2014 · 3 comments

Comments

@aaronj1335
Copy link

@necolas the other day in https://gitter.im/webpack/webpack you suggested using a global variable map as a workaround for full-blown variable parsing on individual CSS modules (wish i could link to the convo, but it was around Sept 8th at ~11 AM PST).

it was pretty straitforward to implement, as you suggested, but the global variables are overwritten by the local defaults, which is a problem when working with suitcss-style packages, because they usually define local defaults.

does any of that make sense?

one proposal would be to provide another config flag to rework-vars that specifies whether the map is overwritten or not. another would be to accept a function that resolves the conflict given some context info.

what do you think? i'd be happy to submit a PR.

@aaronj1335
Copy link
Author

after thinking about this more, another stop-gap is to make a rework plugin that strips the local variable definitions that are already in the map. this avoids the issue without complicating the rework-vars api, so i'm not really sure if any action is needed here.

@necolas
Copy link
Contributor

necolas commented Sep 27, 2014

perhaps the JS variables should not be be overridden? or they get added after everything is extracted from the css.

@aaronj1335
Copy link
Author

yea i think you'll get the same behavior either way right? adding the JS-defined vars after extracting sounds like a clean way to do it. also seems like that should be the default, tho i've got limited experience with this. we could also add a config for applying before or after.

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

2 participants