swc as a javascript parser

[kdy1]

Feature request

Follow up of #13408 (reply in thread)

I'm author of the swc project and I'm looking for way to improve the performance of webpack.

Parsing something in javascript is a very expensive task, so I think using the parser of swc with libuv worker thread will improve performance a lot. (Also, it does not block js thread, so other codes can run while parsing.)

But currently, webpack does not allow overriding dependency analysis and it seems like I have to reimplement the whole JavascriptPlugin. If there's an easier way to improve performance, it would be great.

I'll create a standalone parser package if required.

What is the expected behavior?

Returning dependency graph from a loader.

What is motivation or use case for adding/changing the behavior?

Huge performance improvements.

How should this be implemented in your opinion?

By returning graph object or list from a loader.

Are you willing to work on this yourself?

Yes.

[alexander-akait]

@kdy1 Let's start, does swc is using estree compatibility tree?

Because I think we can add hook(s) on parser stage so you can change acorn parser on swc. Or you can provide more information? Do you want avoid double parsing right?

[kdy1]

Parsing in javascript is slow, and blocks the js thread for a while, so I want to see if it's possible to offload parsing to nodejs thread pool using swc. I think double parsing with swc is not a big problem, as it the not block js thread.

But I'm not sure if it's estree compatible. It can emit the ast of babel, but I'm not sure if the babel ast is estree.

add hook(s) on parser stage so you can change acorn parser on swc.

If this is possible, it would make the job much easier
I was actually considering other things like forking JavascriptPlugin

[alexander-akait]

But I'm not sure if it's estree compatible. It can emit the ast of babel, but I'm not sure if the babel ast is estree.

Should be yes (due https://github.com/estree/estree#estree-steering-committee, but need check), but here other problem webpack understand only stage 4, so if you return new/unknown AST node the result will be unpredictable.

Parsing in javascript is slow, and blocks the js thread for a while, so I want to see if it's possible to offload parsing to nodejs thread pool using swc. I think double parsing with swc is not a big problem, as it the not block js thread.

Can you describe it deeply? Do you want handle js parsring/code generation in multi threading? Maybe you can provide place where you need inject cwd?

[kdy1]

here other problem webpack understand only stage 4, so if you return new/unknown AST node the result will be unpredictable.

swc supports stage 3+ and swc has compatibility transforms so it would not be a problem.

Can you describe it deeply? Do you want handle js parsring/code generation in multi threading? Maybe you can provide place where you need inject cwd?

What I want to do is reducing time used by the parser.
Using other threads is a kind of way to achieve it.

And by

I think double parsing with swc is not a big problem, as it the not block js thread.

I mean parsing twice would not affect performance greatly.
Parsing twice, once from the loader and once from the alternative JavascriptPlugin would result in acceptable performance.

[alexander-akait]

What I want to do is reducing time used by the parser.
I mean parsing twice would not affect performance greatly.

But why do not use loader in this case? I'm a little confused, maybe you can show it using pseudo code on JavascriptPlugin?

[kdy1]

Oh, you are right.
Loader is not required at all in this case.

[webpack-bot]

This issue had no activity for at least three months.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

[alexander-akait]

@kdy1 still valid?

[kdy1]

@alexander-akait Of course, I'd be happy to make it faster.