You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an idea to fix the known limitation about duplicate names:
All your types should have different names inside a bundle. If you have 2 interface Options {} they will be merged by TypeScript and you will get wrong definitions.
The language service can be queried for a list of all locations to replace in order to rename an identifier. Can this functionality be used to rename symbols, avoiding naming collisions?
For each top-level declaration, we can decide if it needs a new name. If it does, we ask the language service for a list of all locations where that name appears. Then as we're emitting the bundled declaration, we perform replacement of all those text spans, which means the symbol gets its new name in the output.
I'm sure there are problems with this approach, and I'm interested to hear what you think.
The text was updated successfully, but these errors were encountered:
It's an interesting idea, but I'm not sure whether it's possible or will be simple, because to rename property we need to detect all collision names, detect in what types we have that nodes and rename there (but what if we'll have 2 different collisions but used in the same type?). If you any rough impl of that, it'd be interesting to see how it works.
This is an idea to fix the known limitation about duplicate names:
The language service can be queried for a list of all locations to replace in order to rename an identifier. Can this functionality be used to rename symbols, avoiding naming collisions?
For each top-level declaration, we can decide if it needs a new name. If it does, we ask the language service for a list of all locations where that name appears. Then as we're emitting the bundled declaration, we perform replacement of all those text spans, which means the symbol gets its new name in the output.
I'm sure there are problems with this approach, and I'm interested to hear what you think.
The text was updated successfully, but these errors were encountered: