For milestone 1, I think it's safe to just layout all the
transformations manually.
In TypeScript, the transformers are collected dynamically and ran on
each ast node; this achieves a single AST pass.
https://github.com/microsoft/TypeScript/blob/main/src/compiler/transformer.ts#L129-L145
To maximize performance and reduce confusion, I think it's safe to
layout all the transformations manually for milestone 1.
The next PR will add transformation context to all presets so we can
start adding "context".
A fix for the work done in: https://github.com/oxc-project/oxc/pull/2905
The existing code checks if _all_ import entries in a ModuleRecord are
type-only, when determining if the ModuleRecord should be skipped when
checking for cycles. This is incorrect.
To demonstrate the problem: Running the `no-cycles` rule, with
`ignoreTypes` enabled, on the following example code will cause a cycle
to be reported between Module A and Module B
```typescript
// Module A
import type { Bar } from './b';
import { Baz } from './c'
// Module B
import type { Foo } from './a';
// Module C
export const Baz = 'baz';
```
The reason this is happening is because the import to Module C in Module
A is causing the `was_imported_as_type` variable to evaluate to `false`,
since the Module C import is not type-only.
What we actually want to do is skip visiting Module B entirely, by
checking if its import request from Module A is type-only.
This PR fixes the logic so that only the import entries for the next
ModuleRecord are considered when determining `was_imported_as_type`.
Added tests to figure out what the problem from the issue was and
realize the self closing tag was not expected. Added code to handle this
case.
I am not that familiar with astro to know how common self closing script
tags are, their docs seem to use an opening and closing one for inline
scripts
https://docs.astro.build/en/guides/client-side-scripts/#load-external-scripts
While looking into this, I knew vue would have similar problems. Which
then led me to realize the generic case was handled already so I tried
abstract out the function so both the vue and svelte partial loaders
could reuse the code. Finally added some svelte test cases to prove this
resolved the issue.
I am a bit new to rust so if there was a better way to reuse the
find_script_closing_angle function open to suggestions.
# What This PR Does
Symbols declared inside exported functions and classes were being
incorrectly flagged with `SymbolFlags::Export`.
For example,
```ts
export function foo<T>(a: T) {
let b = String(a)
return b
}
```
`T`, `a`, and `b` were all flagged as exported.
## Further Work
It doesn't seem like exported enums and interfaces are being included in
`ModuleRecord`. Am I looking in the wrong place, or are they actually
missing?
This would fix the issue found in #2877,
As it is right now, the `FinallyClause` gets visited 2 times, once as
the Finally and once as a block.
This PR addresses this issue by making the `visit_finally_clause` method
visit the body statements instead of visiting the block itself. Now it
works similar to the `CatchClause`.
