You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
@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.
The text was updated successfully, but these errors were encountered: