Closed SukkaW closed 1 year ago
ping @huozhi
Is that possible to use onLog to fix ignore the warning? editing the code is bit tricky if you already found that span
in swc might not be super reliable. Another reason is what if other plugin also checks the directives?
Is that possible to use onLog to fix ignore the warning?
Probably not. The warning from rollup is intentional, to let library developers know they should take actions. rollup-swc-preserve-directives-plugin
is just one of the possible action that library authors could take.
Also, the warning also shows if the plugin is working properly.
editing the code is bit tricky
rollup official plugins also use magic-string
to manipulate code, so I guess it is safe: https://github.com/search?q=repo%3Arollup%2Fplugins%20magic-string&type=code
if you already found that
span
in swc might not be super reliable.
Actually it is a bug of the swc's JS API. And the swc team decides to ignore the issue, since in the next major version of swc (swc v2) there will be no swc.parse
JS API at all anyway.
For now, we can use tests and snapshots to ensure the current workaround works reliably.
In the future PR, I will migrate away from swc.parse
to use the rollup's built-in this.parse
plugin API instead (which also has stable/reliable span
).
Another reason is what if other plugin also checks the directives?
IMHO, the rollup-swc-preserve-directives-plugin
should be added after every other plugin (especially after the swc/babel transformation).
In the future PR, I will add order: 'post'
declaration to the transform
hook : https://rollupjs.org/plugin-development/#build-hooks
rollup official plugins also use magic-string to manipulate code, so I guess it is safe: github.com/search?q=repo%3Arollup%2Fplugins%20magic-string&type=code it's not related to magic string but we're deleting the comment
In the future PR, I will migrate away from swc.parse to use the rollup's built-in this.parse plugin API instead (which also has stable/reliable span).
that's also the purpose of this plugin that swc.parse
is much faster than acorn parse and will have interpreter information.
Actually it is a bug of the swc's JS API. And the swc team decides to ignore the issue, since in the next major version of swc (swc v2) there will be no swc.parse JS API at all anyway.
can you share more where did you se it's going to be deprecated?
that's also the purpose of this plugin that
swc.parse
is much faster than acorn parse
The swc is only fast when it is inside the rust world. That's to say, when moving the AST struct from the rust world to the AST JSON in the js world, the swc becomes so slow that it actually becomes slower than the acorn (And that's why the swc team wants to remove the parse
JS API in v2 in the first place).
Check out this benchmark (https://replit.com/@isukkaw/GoldenVividDebuggers), where the swc parse is about 40% to 60% slower than the acorn.
and will have interpreter information.
The hashbang/shebang/interpreter is very simple and can be easily ported:
interpreter
lexer inside the swc is very primitive: https://github.com/swc-project/swc/blob/7bf4ab39b0e49759d9f5c8d7f989b3ed010d81a7/crates/swc_ecma_parser/src/lexer/mod.rs#L204In short, we don't really need swc to do this.
can you share more where did you see it's going to be deprecated?
https://github.com/swc-project/swc/issues/1366#issuecomment-900805854 https://github.com/swc-project/swc/issues/1366#issuecomment-902455836
The PR does 2 things: