This PR introduces two type alias to avoid the confusing const generic `pub struct Codegen<'a, const MINIFY: bool>`
* CodeGenerator - Code generator without whitespace removal.
* WhitespaceRemover - Code generator with whitespace removal.
Usage is changed to a builder pattern:
```rust
CodeGenerator::new()
.enable_comment(...)
.enable_sourcemap(...)
.build(&program);
```
The typescript transform pass is now required to strip typescript syntax
for codegen to print things properly.
Codegen will now print whatever is in the AST.
close: #3620
In `Babel`, the expected output is:
```ts
var x = 10;
var Foo = function(Foo) {
Foo[Foo['a'] = 10] = 'a';
Foo[Foo['b'] = 10] = 'b';
Foo[Foo['c'] = 30] = 'c';
return Foo;
}(Foo || {});
```
IMO, `Foo.b + x` is enough, because `x` is not a const variable. The
output same as with `typescript`
We have a conclusion that codegen will print whatever is in the AST,
instead of having an option to enable printing TypeScript syntax. I plan
to remove codegen's `enable_typescript` option after we strip out all
typescript AST in the transformer typescript plugin.
---------
Co-authored-by: Boshen <boshenc@gmail.com>
Use the `TraverseCtx::generate_uid` method introduced in #3395 to fix
some of the TS namespace test cases.
But... I honestly have no idea what I'm doing here!
I am running up against a combination of 3 different areas where I know
very little:
1. I am unfamiliar with `Semantic`.
2. I am unfamiliar with Oxc's conventions for writing transforms.
3. I don't "speak" Typescript!
This PR should not be merged as is. I'm pretty sure it's wrong. I've
done it mostly just to test out `generate_uid`.
In particular:
1. Is `SymbolFlags::FunctionScopedVariable` the right flags to use in
all cases here?
2. `generate_uid` creates a symbol, and registers a binding for it in
the scope tree. So if there are any branches in this logic where `name`
doesn't actually get used after `generate_uid` is called, then it's not
right.
3. Identifiers which are added to AST should also have corresponding
`ReferenceId`s created for them (but I imagine this is also missing in
many other places in the transformer).
On point 2: We could split up `generate_uid` into 2 functions. One
function would find a valid UID name *but not register a binding for
it*. If you want to actually use that name, you'd call a 2nd function to
generate the binding. Would that be a better API?
Could someone help me out to progress this please?
(Sorry my lack of knowledge is a bit useless here. I will learn all
these things in time, but just trying to be honest about where I'm at
right now. I'm sure I could figure it out myself, but it would take me
hours, whereas others will probably look at it and know what to do in
about 5 mins.)
Move `BabelOptions` to Transformer. The `output.json` is a standard babel configuration. We can reuse BabelOptions to read [babel.config.json](https://babeljs.io/docs/configuration#babelconfigjson) or our configuration(maybe oxc.config.json)
The current `from_babel_options` implementation is copied from the `transform_options` in `test_case.rs`, which I'll completely reimplement next
If submodules are outdated, it'll panic with the following message
```
Repository is outdated, please run `just submodules` to update it.
```
For us maintainers, we'll need the env `UPDATE_SNAPSHOT` to force an update.
Sliced off from #3152.
Re-implement `transform-react-display-name` using bottom-up lookup
provided by `Traverse` trait.
This fixes the 1 remaining failing test case for this plugin (see
#2937).
`Traverse` is not complete yet (see #3182), so this is also not ready to
merge yet.
