fix: replace special characters using SPECIAL_CHARACTER_MAP for dup…

[phk422]

…licate-identifiers

Changes

reference: #1874

How to Review

All test cases should pass

Checklist

• Unit tests updated
• docs/ updated (if necessary)
• pnpm run update:examples run (only applicable for openapi-typescript)

[changeset-bot]

🦋 Changeset detected

Latest commit: fdba84e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
openapi-typescript	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[yoshi2no]

This issue #1874 is related to the PR #1761 I previously submitted so Thank you @phk422 for working on this issue! 🙏
As you are doing, if we handle this by creating the SPECIAL_CHARACTER_MAP and replacing characters, I think we would need to map all of the following characters to completely avoid enum name collisions. It might be necessary to either create a complete map or add quotes if there’s even a single invalid character(I would say this is a simpler solution). What do you think? 🧐

This list was generated by ChatGPT, so it needs to be reviewed to ensure it’s comprehensive.

- `+` (Plus)
- `-` (Minus or Hyphen)
- `*` (Asterisk)
- `/` (Slash)
- `.` (Dot)
- `,` (Comma)
- `:` (Colon)
- `;` (Semicolon)
- `=` (Equals)
- `!` (Exclamation mark)
- `@` (At symbol)
- `#` (Hash)
- `$` (Dollar sign, though `$` itself is valid if used correctly)
- `%` (Percent)
- `^` (Caret)
- `&` (Ampersand)
- `(` (Left parenthesis)
- `)` (Right parenthesis)
- `{` (Left curly brace)
- `}` (Right curly brace)
- `[` (Left square bracket)
- `]` (Right square bracket)
- `|` (Vertical bar or pipe)
- `\` (Backslash)
- `'` (Single quote)
- `"` (Double quote)
- `<` (Less than)
- `>` (Greater than)
- `?` (Question mark)
- `~` (Tilde)

[phk422]

This issue #1874 is related to the PR #1761 I previously submitted so Thank you @phk422 for working on this issue! 🙏 As you are doing, if we handle this by creating the SPECIAL_CHARACTER_MAP and replacing characters, I think we would need to map all of the following characters to completely avoid enum name collisions. It might be necessary to either create a complete map or add quotes if there’s even a single invalid character(I would say this is a simpler solution). What do you think? 🧐

This list was generated by ChatGPT, so it needs to be reviewed to ensure it’s comprehensive.

- `+` (Plus)
- `-` (Minus or Hyphen)
- `*` (Asterisk)
- `/` (Slash)
- `.` (Dot)
- `,` (Comma)
- `:` (Colon)
- `;` (Semicolon)
- `=` (Equals)
- `!` (Exclamation mark)
- `@` (At symbol)
- `#` (Hash)
- `$` (Dollar sign, though `$` itself is valid if used correctly)
- `%` (Percent)
- `^` (Caret)
- `&` (Ampersand)
- `(` (Left parenthesis)
- `)` (Right parenthesis)
- `{` (Left curly brace)
- `}` (Right curly brace)
- `[` (Left square bracket)
- `]` (Right square bracket)
- `|` (Vertical bar or pipe)
- `\` (Backslash)
- `'` (Single quote)
- `"` (Double quote)
- `<` (Less than)
- `>` (Greater than)
- `?` (Question mark)
- `~` (Tilde)

Thank you for your suggestion, I also thought about adding all characters, but I think it will have some impact on the type generation of existing users. Considering the probability of #1874 appearing in the actual use process is relatively small, so I think to solve specific problems; As for the solution with quotation marks, although it seems simpler for this problem, it will also have a big impact on the use of our current users (personally, I don't like the style of quotation marks, haha...) . Above, I'd also like to hear from @drwpow

[drwpow]

This is a great fix, thank you! Please add a patch changeset so this can be released.

[drwpow]

Considering the probability of #1874 appearing in the actual use process is relatively small, so I think to solve specific problems … I'd also like to hear from @drwpow

Agreed with @phk422; enum collision is something that can be done incrementally, and with a light touch at first. We shouldn’t risk changing generated types if at all possible, too (not without a valid usecase).

We don’t have to handle all possible scenarios, just so long as we are handling collision at a basic level. I don’t have specific data on this, but just anecdotally, schema collision does happen in large schemas split between multiple files. But like @phk422 said it’s pretty rare for there to be more than a conflict or two (if there is at all). So I’d prefer to take approaches like this PR does—just add one usecase at a time, only when we’ve confirmed it’s a common-enough scenario that someone has run into it.