+1 for this. I assumed that

pluralize.plural("IP") //=> "IPS"
pluralize.addPluralRule(/IP$/, "IPs")
pluralize.plural("IP") //=> "IPs" // DOES NOT WORK LIKE THIS

would work, but it still outputs "IPS".

I have a solution, will throw a PR to this and as well capture some missed cases as well

it("should allow new plural matching rules", function () {
      expect(pluralize.plural("vIP")).to.equal("vIPS");

      pluralize.addPluralRule(/vIvP$/i, "vIvPs");

      expect(pluralize.plural("vIvP")).to.equal("vIvPs");
    });

    it("should allow new plural matching rules", function () {
      expect(pluralize.plural("IP")).to.equal("IPS");

      pluralize.addPluralRule(/IP$/i, "IPs");

      expect(pluralize.plural("IP")).to.equal("IPs");
    });

    it("should allow new plural matching rules", function () {
      expect(pluralize.plural("Blank Application2")).to.equal("Blank Application2s");

      pluralize.addPluralRule(/tion2$/i, "tion2S");

      expect(pluralize.plural("Blank Application2")).to.equal("Blank Application2S");
    });

Create the PR https://github.com/blakeembrey/pluralize/pull/136

This is not an easy thing to fix and anyone wanting a fix should specify how they think it should work overall, not just in their one use-case. Both these examples assume pluralization is just adding an s, but what about WHISKY? That would become WHISKIES today, but under a naive lowercase it"d be WHISKies, which doesn"t make much sense.

The simplest thing would be to remove all case changing, but I suspect that some people do rely on this behavior today. This is especially important to do correctly once, since this library has been functionally equivalent for over 6 years, but this issue has only been request in the past couple of months.

I can see the complexities in the WHISKY example, however, it would be helpful even to have the ability to explicitly add a mapping such as API --> APIs via addPluralRule or even addIrregularRule if you want to consider it an "irregular" rule.

Definitely! Any thoughts on what the API should look like to support this?

Edit: The only obvious idea I have is adding a "sensitive" option to the add APIs that skips changing things. I.e. if you say "sensitive" it will not change what you added to the library, so it will return you WHISKies in that example.

If you have an exact (string) plural rule (e.g. pluralize.addPluralRule("IP", "IPs")), I think it"s safe to ignore the casing since you"ve explicitly defined the plural version. Unfortunately, looking at the code, it seems the library converts string plural rules into a regex 😅 .