Your org has enabled the Graphite merge queue for merging into main

Add the label “0-merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

• refactor(transformer): re-implement ModuleImports #6177
• refactor(transformer/react): don't follow the Babel's imports order #6176 👈
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Dunqing and the rest of your teammates on Graphite

CodSpeed Performance Report

Merging #6176 will not alter performance

_{Comparing 09-30-refactor_transformer_react_don_t_follow_the_babel_s_imports_order (73cfb59) with main (f2ac584)}

Summary

✅ 29 untouched benchmarks

Personally I am not keen on diverging from Babel at this stage.

My feeling is that Babel's transformer tests which we are using for conformance are not enough. To really test the transformer, we need to throw a lot more code at it. The best way I can see to do that is something like this:

• Crawl all the JS/TS files from the top 1000 npm packages.
• Run each of them through both Babel and Oxc transformer.
• Compare the outputs.

When we have no mismatches all all, we can have high confidence that our transformer is bug-free (or at least has no more bugs than Babel). But to run those tests without spurious differences in the diffs, we need our transformer's output to match Babel's exactly - even in cosmetic aspects like statement order.

I'll look into this further and try to find if we can achieve what we're trying to do (move ModuleImports into common) without failing any tests. I think it should be possible.

@overlookmotel Feel free to take over this stack, I am on holiday now. 🏖️

#6183 negates the need for this.