Skip to content

Additional names for units #739

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
j0hnm4r5 opened this issue Apr 8, 2025 · 2 comments
Open

Additional names for units #739

j0hnm4r5 opened this issue Apr 8, 2025 · 2 comments
Labels
enhancement New feature or request

Comments

@j0hnm4r5
Copy link
Contributor

j0hnm4r5 commented Apr 8, 2025

This probably belongs more in a discussion area than as an issue, but I don't see one, so here we go!

I'm looking for your thoughts on the best way to handle additional unit names, specifically ones that are underscore separated or camel/Pascal case.

Options

  1. Convert them manually before running them through the convert library. The downside of this is that you lose typesafety since it's happening at runtime. The upside is that the library remains opinionated.
  2. Update the codebase with new names for every unit. The downsides are added codebase complexity and maintainability is decreased (especially if there's ever a need to add more names in the future). The upside is there's no major modifications to how the library works.
  3. Convert them within convert. Similar to 1, but a nicer experience for any library users.
@j0hnm4r5
Copy link
Contributor Author

j0hnm4r5 commented Apr 8, 2025

This package looks great: https://www.npmjs.com/package/change-case

@jonahsnider jonahsnider added the enhancement New feature or request label Apr 11, 2025
@jonahsnider
Copy link
Owner

Unfortunately, I don't think there's really a good way to add this functionality directly to convert, your best option is probably the 1st one you listed.

The downsides you listed under option 2 are pretty spot-on, it'd be quite a headache to just add in a bajillion aliases for each supported name format. Option 3 of doing the normalization in convert would work, but it seems tricky to make that work reliably & without hurting performance. The types would probably be a headache to make work but seem like TS is powerful enough to handle that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants