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

new deconflict strategy for dealing with conflict names #389

Open
underfin opened this issue Nov 25, 2023 · 2 comments
Open

new deconflict strategy for dealing with conflict names #389

underfin opened this issue Nov 25, 2023 · 2 comments

Comments

@underfin
Copy link
Contributor

If some symbols conflict, need to assign a new name to avoid name conflict. Here has two strategy to assign new name.

  1. the assigned new name is a new name at scope. Esbuild used it.
  2. the assigned new name maybe conflict and also rename conflict names.

Think the scope has a/a$1/a$2 symbols declared. The strategy 2 will caused a/a$1/a$2 every symbol need to rename, The strategy 1 will only rename once a -> a$3.

Original discuss is here #365.

@underfin
Copy link
Contributor Author

underfin commented Mar 28, 2024

  1. the assigned new name is a new name at scope. Esbuild used it.

We should use it, because it will reduce soucemap token names size, and it will reduce the overhead of name hash calculate and vlq mapping.

related oxc-project/oxc#2753.

@hyf0
Copy link
Member

hyf0 commented Mar 28, 2024

I understand esbuild could assign new name in one shot. But I'm not sure I understand this. Could you give an example to show why now we will generate more types for names filed of sourcemap.

And for the generated sourcemap, how much we are bigger than esbunild.

@hyf0 hyf0 changed the title Renamer assign new symbol name strategy. new deconflict strategy for dealing with conflict names Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants