Skip to content
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

Behavior of PascalCase #198

Closed
ulken opened this issue Apr 1, 2021 · 4 comments
Closed

Behavior of PascalCase #198

ulken opened this issue Apr 1, 2021 · 4 comments

Comments

@ulken
Copy link
Contributor

ulken commented Apr 1, 2021

I'm using pascal-case (as part of change-case) which seems to take a slightly different specification route than type-fest's PascalCase type. As a result, they don't play well together.

The difference comes down to how numbers are treated. pascal-case prefixes delimited numbers with _. PascalCase simply merges it with the preceding word.

Examples
pascalCase("foo-1") // "Foo_1" vs. PascalCase<"foo-1"> // "foo1

Personally, I prefer pascal-case's take on this one, but I would like to hear if there has been any explicit reasoning around the current behavior or if it just hasn't been thought of.

The main reason is being to able to convert to and fro two casings:

paramCase(pascalCase("foo-1")) // "foo-1"

Which just isn't possible with PascalCase:

KebabCase<PascalCase<"foo-1">> // "foo1"

@ulken
Copy link
Contributor Author

ulken commented Apr 1, 2021

Or rather, if it somehow could be configurable (as is the case with param-case). I had a look at rolling my own version using DelimeterCase, but as far as I understand, it's currently not possible.

@sindresorhus
Copy link
Owner

I think Foo1 is the correct output. Foo_1 is not pascal case. Pascal case doesn't have any underscores. Also, an underscore would fail linting in most projects.

One of the most popular camelcase/pascalcase packages on npm also has this behavior: https://github.com/sindresorhus/camelcase/blob/a83fd06fc15538d92deacbdfdcb397d9dbec68ed/test.js#L81

@sindresorhus
Copy link
Owner

The main reason is being to able to convert to and fro two casings:

Two-way conversion is a non-goal.

@ulken
Copy link
Contributor Author

ulken commented Aug 12, 2021

I hear you. Thank you for givning your view on the matter.

@ulken ulken closed this as completed Aug 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants