Pluralization is broken

[ShahriarKh]

Package version

6.2.2

Describe the bug

When I want to create new models or controllers (and probably other things), the name formatter behaves wrongly in some cases. For example, try:

node ace make:model cookies

This creates cooky.ts!

This happens for many other words, including made-up words.

I investigated a bit, and seems like the problem comes from pluralize library which is used under the hood by poppinss/utils. Pluralize was last updated in 2019, and has many open pull requests.

So, 3 possible solutions come to my mind:

1. replace pluralize or fork it to fix this bugs and avoid conversion of made-up words
2. add a flag for all make:* commands to prevent this auto fix.
3. instead of changing the word automatically, add an extra step in cli to ask users if they want their new controller/model/... name to be changed or not... something like:
   Do you want to change "CookiesCOntroLLer" to "cooky"? (Y/n)

Reproduction repo

No response

[kyr0]

Don't try to switch to the fancy compromise library; which is an amazing lib.. but it gets this wrong too. I was about to post that this would be a great alternative, but it's not. Demo: https://codesandbox.io/p/sandbox/compromise-forked-h2vg55

[thetutlage]

Not sure what really the solution is, if most of the popular libs get it wrong.

But I agree, bypassing the transformation with a flag seems like a nice middle ground. Not in favor of a prompt.

[ShahriarKh]

Or maybe some config in package.json or elsewhere:

"autoFixNames": {
  "controllers": "always",
  "models": "never",
  ...
}

This also introduces the possibility of letting devs choose their naming conventions. For example: "models":"PascalCase"

I know it makes it more complex to implement, but it has its use cases.

[RomainLanz]

Or maybe some config in package.json or elsewhere:

"autoFixNames": {
  "controllers": "always",
  "models": "never",
  ...
}

This also introduces the possibility of letting devs choose their naming conventions. For example: "models":"PascalCase"

I know it makes it more complex to implement, but it has its use cases.

People can already change all scaffolding option https://docs.adonisjs.com/guides/scaffolding

[ShahriarKh]

Oh, so I think the flag is the way to go. The CLI should either use defined (or default) naming conventions and do the autofix, or skip them and use the provided name if a flag is present.

[kyr0]

The best option would probably be, to impement and release a decent pluralization lib based on wordnet dataset, or else. Idk if I'll find the time to do that, but that's basically the only accurate solution. Grammar rules won't ever catch all the fish there is. It could be fun to optimize this by computing a xor checksum on the diff of the dataset that works well by grammar rule computation (optimization on-disk index size), and have a lookup table for all else words that fail. Re-building the lib automatically when a new mistake is reported, for maintainers to quickly include fixes from upstream. Would be fun.. and a nice example for my brotli compress lib xD

[rnwonder]

Seems it was fix on pluralize github version not on the npm version according to this issue

[github-actions[bot]]

This issue has been marked as stale because it has been inactive for more than 21 days. Please reopen if you still need help on this issue

[RomainLanz]

Keep open

[github-actions[bot]]

This issue has been marked as stale because it has been inactive for more than 21 days. Please reopen if you still need help on this issue

[dunhamjared]

Oooooh, this is a tricky one.

[RomainLanz]

When I have some time (which might not be soon), I'll develop a new module using the Doctrine Inflector API to replace our current pluralization API. It'll be a framework-agnostic package under the BoringNode organisation.

[github-actions[bot]]

This issue has been marked as stale because it has been inactive for more than 21 days. Please reopen if you still need help on this issue

[github-actions[bot]]

This issue has been marked as stale because it has been inactive for more than 21 days. Please reopen if you still need help on this issue