Added camelCase option

[nkt]

This patch helps developers use css-modules with external libraries, like bootstrap. Popular css frameworks use kebab-case (bootstrap, foundation), or maybe other, like snake_case. We can resolve this problem if would automatically convert them to camelCase.

/* styles.css */
.btn-info {
  color: blue;
}

// app.js
const styles = require('!css?modules&camelCase!./styles.css');

console.log(styles.btnInfo) // _38r5hlPyrqKLodJwWOdM1k
console.log(styles['btn-info']) // undefined

[blia]

👍

[nkbt]

👍 nice

[nkt]

@sokra ping

[blia]

Can You keep both versions(original, camelCase) in result scope?
For intuitive using as strings in bound scope?
Example:

/* styles.css */
.btn-info {
  color: blue;
}
.is-loading {
  color: red;
}

// app.js
const styles = require('!css?modules&camelCase!./styles.css');
const cx = require('classnames/bind').bind(styles);
// as strings
const classNamesA = cx('btn-info', 'is-loading');
// as logical notation
const classNamesB = cx('btn-info', { isLoading : true });
const isLoading = true;
const classNamesC = cx('btn-info', { isLoading });
console.log(classNamesA) // =>  "__btn-info___xCfnx __is-loading___3sOhl"
console.log(classNamesB) // =>  "__btn-info___xCfnx __is-loading___3sOhl"
console.log(classNamesC) // =>  "__btn-info___xCfnx __is-loading___3sOhl"

[b2whats]

👍

[chicoxyzzy]

great feature

[nkt]

@sokra ping

[sokra]

@nkt yes, great feature. Could you keep both versions(original, camelCase) in result scope as @blia suggested?

[nkt]

@sokra done

[sokra]

Thanks

[faergeek]

@nkt @sokra It somehow doesn't work for css/locals loader (i.e. on server)

[faergeek]

It should be move from loader.js to processCss.js probably?

[nkt]

@faergeek yep. I'm working on this.

[faergeek]

Cool, it should probably just be factored out from loader.js to use it from both localLoader.js and loader.js?.

Cool feature, BTW 👍

[faergeek]

Would be cool to have possibility to use camelCase which replaces only dashes, leaving underscores alone, what do you think?

[nkt]

@faergeek now it's keeping both variants.

[faergeek]

I mean if we have class like menu-item_disabled (BEM naming) it should result in menuItem_disabled instead of menuItemDisabled to allow it's usage as identifier in js, but still distinguish modifiers from elements :-)

[faergeek]

I could contribute this functionality into your fork

[faergeek]

Or I could just make a separate PR which will add it to css/locals loader and add option for camelCasing if you're busy now

[nkt]

@faergeek I've published new PR.
I guess you're suggesting another mode of camel-casing, so you can add it as option:
"loader": "style!css?modules&camelCase" - already contributed camelCase behavior, standard.
"loader": "style!css?modules&camelCase=bem" - new behavior specially for BEM.

[faergeek]

Yes, but probably use another name for that or just alias it (camelcase=dashes-only or camelcase=identifiers or something like that may be?).

[sokra]

Just don't use BEM when using CSS Modules. That makes no sense. Instead of menu-item_disabled use disabled. You don't need namespacing in your class names, it's namespaced by the file.

[faergeek]

@sokra I think it's still convenient to distinguish between element and modifier.
CSS Modules eliminate the usefulness of blocks, but modifiers still a good thing I think :-)

So I can have multiple elements with disabled modifier like item_disabled and list_disabled and still can understand that it's a modifier and not an element like item-disabled or list-disabled.

[sokra]

ok, you are propably right.

[kumarharsh]

@sokra @nkt would it be possible to introduce yet another flag which removes the uncamelized version?
I'm asking because of a comment on one of the issues: clinyong/vscode-css-modules#3 (comment)

Basically, by retaining both the camelized and original versions of a classname, the bundle size increases, sometimes by a lot for larger projects. If all developers are in with the syntax, perhaps it'd not be as problematic to remove the original classnames? Two extra options can be added to the camelCase options: camelCase: only and camelCase: dashesOnly which cause the plugin to not output the original classes. What do you think of the idea?

[joshwiens]

@sokra focuses on webpack and core integrations. @webpack-contrib/org-maintainers is what you are looking for.

A merged pull request from a year ago is not the place to be asking for an enhancement. Create a new issue so it can be properly triaged by the correct group of people.