`outletGSId` becomes `outletGsId` through camel case

[jonaslagoni]

outletGSId becomes outletGsId through camel case function, when in theory I would expect it to do nothing with the value 🤔 Am I missing something here?

Here are the test-case I am running:

    "change-case": "^5.4.4",

import {
  camelCase
} from 'change-case';
describe('camelCase', () => {
    test('should not change outletGSId', () => {
      const content = camelCase('outletGSId');
      expect(content).toEqual('outletGSId');
    });
});

Related to #2
Raised in asyncapi/modelina#2080

[blakeembrey]

This package doesn’t do any detection of what the current “case” is, it just does the conversion following built in rules. Arguably this rule is wrong, and you can override how things are split, but it was design to handle conversion of things like XMLHttpRequest to other cases.

For now it’s not something I plan to fix this since it’s the first time it’s come up, but if I ever do a new major version I’ll consider removing this as the default split behavior.

It sounds like maybe you just want to detect “is camel case” before converting? Those utilities could be added without a breaking change.

[jonaslagoni]

@blakeembrey makes total sense, thanks for the quick reply.

It sounds like maybe you just want to detect “is camel case” before converting? Those utilities could be added without a breaking change.

Might be the best course of action, thanks for the suggestion 🤙

Feel free to close this issue as you see fit 🙂

[Tobbe]

I just ran into this myself. The way other similar libraries have solved this is with an option like preserveConsecutiveUppercase (see https://github.com/jonschlinkert/pascalcase#uppercase-character-sequences). Comes from https://github.com/sindresorhus/camelcase#preserveconsecutiveuppercase