fix: remove rollup warning & separate directives for each output chunk

[SukkaW]

The PR does 2 things:

• Each output chunk will only have its separate directives.
  • This allows the server/client builds with different input entries to have correct directives.
• Avoid rollup warnings about module-level directives.

[SukkaW]

ping @huozhi

[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?

[SukkaW]

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

[huozhi]

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?

[SukkaW]

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:

• The interpreter lexer inside the swc is very primitive: https://github.com/swc-project/swc/blob/7bf4ab39b0e49759d9f5c8d7f989b3ed010d81a7/crates/swc_ecma_parser/src/lexer/mod.rs#L204
• The shebang lexer inside the acorn is also very primitive: https://github.com/acornjs/acorn/blob/8da1fdd1918c9a9a5748501017262ce18bb2f2cc/acorn/src/state.js#L78

In 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