change: remove aggregated node types as it may enduce conflicts

[maastrich]

what does it do ?

• remove AggregatedType
• remove hanlders for AggregatedType

why is it useful ?

AggregatedType led to think that we can listen on nodes like Property while it is not the case, no node will have a type Property but it will be Identifier, KeyValueProperty, ...

A second reason is that aggregated types swc.ImportSpecifier and swc.ExportSpecifier could lead to conflict with swc.NamedImportSpecifier and swc.NamedExportSpecifier whose type property is set to ImportSpecifier and ExportSpecifier respectively.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 53.36%. Comparing base (8f967ab) to head (9fde055).

Additional details and impacted files

@@            Coverage Diff             @@
##             main       #5      +/-   ##
==========================================
+ Coverage   51.69%   53.36%   +1.66%     
==========================================
  Files           2        2              
  Lines         677      624      -53     
  Branches       12       12              
==========================================
- Hits          350      333      -17     
+ Misses        327      291      -36     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maastrich]

note that all removed types form AnyNode is provided by on of the AggregatedNode and will not be lost

[morganney]

Hi @maastrich I will try to get to this later tonight, work has been keeping me busy.

Overall the idea with the AggregateType was that you could attach a handler for one of them, and then filter the logic based on the node's actual type. Are you saying this is not the case/possible, or that there is little value in supporting that?

[maastrich]

Hi @maastrich I will try to get to this later tonight, work has been keeping me busy.

Overall the idea with the AggregateType was that you could attach a handler for one of them, and then filter the logic based on the node's actual type. Are you saying this is not the case/possible, or that there is little value in supporting that?

could be posssible but it should be defined with a way to avoid conflict
it would require to ignore acorn and define a custom ast visitor function 👀

[maastrich]

@morganney what I was thinking is

1. handle "classic" node types as is, the BaseVisitor being meant to walk the AST without actions (it cannot handle AggregatedNodes)
2. handle "classic" AND "aggregated" nodes with the SimpleVisitor object, where any node aggregated within swc.Property would trigger a call for the AggregatedProperty walker

simple(ast, {
   ArrayExpression(node, st) {
      console.log("only trigger for 'swc.ArrayExpression' node")
   },
   AggregatedPattern(node, st) {
      console.log("triggers for 'swc.ArrayPattern | swc.BindingIdentifier | swc.RestElement | swc.ObjectPattern | swc.AssignmentPattern | swc.Expression' nodes")
   }
})

This way, we can ensure that the named of AggregatedNodes and ClassicNodes never conflict 🤔

[maastrich]

should stay never until it is handled ?

[morganney]

Thanks @maastrich this is a reasonable next step.