Hmm I see the problem. I think you can do this with VisitMut, but you'd need to add visitors to keep track of what scope you're in. e.g. visit_function would push the scope_id of the function to a stack, so you can then read it back later. But this means re-implementing all the scope-tracking functionality that Traverse already has. This is possible, but a huge pain.

Actually... could something like this work?

1. Add a flag is_in_enum to TypeScriptEnum.
2. Set that flag to true when entering an enum, and back to false when exiting it.
3. Add a visitor for enter_identifier_reference to TypeScriptEnum.
4. In enter_identifier_reference, it checks if is_in_enum is true, and if it is then it reads ctx.scopes() and can decide whether to replace the identifier or not.

i.e. Do everything in one Traverse pass, instead of traverse-within-traverse.

I think this could work? But maybe I missed something?

Sounds good. I've thought it through. The only problem is previous_enum_members. In each transform enum member. We will cache the value of enum member to previous_enum_members. The reason for doing this is because the initializer of an enum member can use the enum members that have already been defined before it. So we may not solve this case.

I guess it's possible to have an enum within an enum.

enum A {
  a = 1,
  b = function() {
    enum B {
      c = a,
      d = x,
    }
  }
}

so instead of a single flag is_in_enum, would need a stack of "current enums", to support this bizarre use case.

So we may not solve this case.

I don't see the problem with that one. What's the catch? If no binding found in upper scope, it defaults to resolving foo as Enum.foo. So, in that example, is it a problem that d is used before it's defined?

Here is the entry point for the transform enum.

I've thought it over carefully, and it's getting a bit complicated. Because the value of an enum member can be any Expression. If we want to modify the identifier reference after transforming the enum, we may encounter many edge-case

#3314 added all the primitives required to support this. I will build an abstraction around them to produce a generateUid-type API next week.

Please see #3394 and #3395.

@Dunqing As you mentioned in #3395 (comment), it sounds like you're going to tackle the rest of these, now that TraverseCtx::generate_uid is implemented.

But please can you leave the React JSX one for me? I would like to get some practice on the transformer, and it would be easier for me to do that on a JSX transform (where I understand what the transform is doing), rather than TypeScript ones (where I don't understand, because I don't know TS).

Sure, enjoy it.

#3431 solves the React JSX one.

scope.hasOwnBinding and scope.getBindingIdentifier equivalents are now available via the APIs added in #3314.

Not sure about path.resolve - I've not investigated what it does yet.

What is the scope.getBindingIdentifier equivalent api?

path.resolve() is to find the defined node based on the current node. For example, if the current node is an IdentifierReference. The return value of path.resolve is a BindingIdentifier

let a = 0;
    ^
    The result of path.resolve() 
console.log(a) // call path.resolve() here

This one has been addressed in #3229. ctx.scope() gives you ScopeFlags for the current node.

Please see notes in that PR about inheritance of flags from parent scope.

Thank you! These tests were done.

I'll follow up on this.

Need to add an option to disable typescript plugin.

@overlookmotel cc

If I understand how namespace {} works, TSModuleBlock represents the {} part and it has a scope_id.

The transform removes the TSModuleBlock, and replaces with a function. So can we "steal" the scope_id from the old TSModuleBlock and make it the scope_id for the new function instead?

Yes, It's a workaround. I just wanted to let you know that we can do it for now. Their scope flags are different. We may also need to provide a method to change it.

I have done in #3459 #3460. All namespace test cases are done!

All namespace test cases are done!

🍾 Bravo Dunqing!

I will review those 2 PRs later today.

Yes, we definitely need to add new APIs for manipulating scopes, symbols + references.

In this particular case, we should be able to alter the scope flags for the old TSModuleBlock scope via ctx.scopes_mut().

It's not part of the current milestone.