fix: do not export duplicate keys

[joscha]

What kind of change does this PR introduce?

Bugfix, it makes sure that keys that are the same in different case styles (e.g. dashed, camelCase, dashedCamelCase) are not added to the resulting output when ?camelCase is enabled.

E.g. a class name .bla would be bla as a default, but also bla in camelCase whereas .my-bla would yield my-bla and myBla. Currently the constructed document for the locals contains two entries, like this:

{
  "bla": "_1L-rnCOXCE_7H94L5XT4uB",
  "bla": "_1L-rnCOXCE_7H94L5XT4uB",
}

if camelCase is enabled.

Did you add tests for your changes?

No, because the test helper uses JSON deserialization, which removes the dupe.

Summary

When using CSS modules with Typescript for example, you encounter something like this:

ERROR in /Users/joscha/dev/web-ui/src/ui/button/button.css.ts
(11,2): error TS2300: Duplicate identifier '"defaultFontStack"'.

ERROR in /Users/joscha/dev/web-ui/src/ui/button/button.css.ts
(13,2): error TS2300: Duplicate identifier '"button"'.

Also, the resulting output in the bundle is 50% bigger than it has to be if only class names are used that are className === camelCase(className).

Does this PR introduce a breaking change?
No

[codecov]

Codecov Report

Merging #420 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #420      +/-   ##
==========================================
+ Coverage   98.32%   98.36%   +0.03%     
==========================================
  Files           9        9              
  Lines         299      306       +7     
  Branches       67       69       +2     
==========================================
+ Hits          294      301       +7     
  Misses          5        5

Impacted Files	Coverage Δ
lib/compile-exports.js	100% <100%> (ø)	✅

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e02e7a2...be83084. Read the comment docs.

[joscha]

can't find the place to sign the CLA

[joscha]

still no email from the CLA bot :(

[michael-ciniawsky]

👍

[michael-ciniawsky]

@joscha Please close and reopen the PR once again for the CLA, it should work now :)

[bebraw]

I think you have to close/open the PR again as the CLA bot was fixed about ten days ago.

[jsf-clabot]

All committers have signed the CLA.

[joscha]

@michael-ciniawsky @bebraw done

[joshwiens]

You can nest two ternary operators for better readability and the same end result

[joscha]

@d3viant0ne I tried keeping the diff as small as possible - made some changes so it is more readable now, please take another look.

[michael-ciniawsky]

👍 @d3viant0ne @bebraw Please Review :)

[bebraw]

This needs tests so we don't break it again.

[joscha]

@bebraw sure, I will need to change the current tooling a tiny bit for that because right now it is all based on JSON.parse which removes the duplication before we can test it. If that's okay I am happy to add a test for it.

[michael-ciniawsky]

@joscha From my side, just move on :)

[bebraw]

@joscha Ok, cool. Safer with tests. 👍

[joscha]

@bebraw @michael-ciniawsky I added two tests however, there is something really strange happening with the README.md - somehow the line endings get converted and any git config core.autocrlf true, etc. couldn't change it so the README.md doesn't show as changed. Do you have any idea how to fix this, as currently the diff contains the line ending changes.

EDIT: seems to be fixed by #416

[joscha]

The line endings in README seem to be fixed by #416 - for now you can just squash my changes.

[joscha]

I squashed all commits into one, so should be good to go now 👍

[bebraw]

Nice work. I'll let either Michael or Joshua to merge and publish. 👍