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

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

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?

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.

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?

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

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.

Issue was closed because of inactivity.

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

@kdy1 still valid?

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

For at least initial/demonstration purposes, I think tacking on to swc-loader makes sense here (otherwise, we would have to make a bunch of changes to asyncify the parser parsing - not impossible, but isnt necessarily blocking).

Assuming ast's are compatible (which small test indicates they arent, but they may be close)

The simplest way to get this working using swc-loader, IMO:

1. Modify (either always, or by opt-in) the return type of @swc/core transform[Sync] to include an ast property (essentially just the output of swc.parse)
2. Return the parsed AST property as the fourth argument in swc-loader callback { webpackAST: JSON.parse(output.ast)) }
   https://github.com/swc-project/swc-loader/blob/da457e55ac9bc8365e434de95d62324a3bf41cd2/src/index.js#L92
3. Setting this "known" property will allow webpack to skip its built-in acorn parsing, so we are off to the races!

The main incompatible property set that stands out right now, though, is start/end/loc/range properties. I dont see an option to get the exact loc info from swc, and the start/end properties are encapsulated in a seperate span object

Additionally, webpack expects comment blocks to be parsed and available in the AST, which seems to also be missing from swc
@kdy1 lemme know if you need assistance from me, as I am also interested in seeing this happen

edit:i also have done some reading on the issues related to sending back ASTs and see the perf hits, so thats definitely also something to be considered, because the whole JavascriptParser class probabably cant be moved to native due to all the hooks usage

Yeah actually I made rust module that can generate acorn AST from source code. I'll check how it performs using swc-loader first. Of course, it has start/end/loc/comments/etc..
We need benchmark, but definitely worth trying.

@kdy1 as @markjm mentioned AST has to have comments embedded in it. Does you parser include comments too?

@mohsen1 The swc codebase has rust code to create babel/acorn ast and of course those have comments stored in the struct.
Additionally, acorn version is designed to work with webpack (because next.js uses webpack)

I'll add a way to get webpack ast from node js. Filed swc-project/swc#3437

I have one question. Should I add the API to @swc/core?
I'm worried about the size.

@swc/core is quite big because it has lots of code and even a wasm runtime.

@kdy1 @swc/core is great place, it already has parseSync, so why not :).

About comments, does it supported or not? I’m confused a bit 🤔 (swc-project/swc#2964 (comment))

@coderaiser You can don't worry, because if decide to do it (and most likely it will), it will be experiment, so you can report about any problems in swc

It's supported and rust type definitions for acorn/babel AST store comments inline.
But I'm not sure about the binary size and I think I should be careful about adding an API.

@alexander-akait I also waiting for ability to use rust-based solution to produce estree or Babel AST.

I’m working on linter 🐊Putout that can fix everything it can find and on tool that converts swc AST to Babel and SWC AST has no comments support, I’m also working on tool that converts ESTree to Babel which does it’s job perfectly.

So, thank you, but I cannot not worry :), since it’s related to software I’m working on.

@kdy1 Here is one of the ways how API can look like:

const {parseSync} = require('@swc/core');
const ast = parseSync(`const hello = 'world'`, {
    type: ‘estree | babel | swc (default)’
});

No need to use any experimental flags, such API is obvious and straight forward, and of course any bug will be reported to swc repo :).

Worry not about bundle size, if it will be less then one that TypeScript has it will be already amazing 😏. But practical usage is more useful then very long term planning.

@coderaiser Yep, it is not hard task, we need add new options to allow setup parser in webpack (and mark it as experimental so we can do breaking changes between versions) and add cross tests to check all our tests (I think we can catch some problems on early stage).

For for your interest we are working on rust based linter solution https://github.com/swc-project/swc/tree/main/crates/swc_ecma_lints, so if you want to be more faster and safely you can help ⭐

For for your interest we are working on rust based linter solution https://github.com/swc-project/swc/tree/main/crates/swc_ecma_lints, so if you want to be more faster and safely you can help ⭐.

I am interested. I’m not as good in rust as in JavaScript 😅, but I have two questions:

🤷 Why so much code for such simple task, as warning about DebuggerStatement?

☝️49 Lines! Compare it to 7 lines of remove-debugger:

'use strict';


module.exports.report = () => 'Unexpected "debugger" statement';


module.exports.replace = () => ({
    debugger: '',
});

It reminded me the case with hasOwn, when 🐊Putout implementation had 6 lines vs 112 of ESLint 😏. So don’t tell me that this is because of Rust syntax 😸.

🤷 Where is the fix?

Look, I don’t think that program should tell me what to do, what it really should do: is does things 🤖! So ability to fix is mandatory for linter, that’s why 🐊Putout exists.

🎈Anyways…

…Anyways, I have something to suggest you: 🐊PutoutScript: JavaScript with superpowers: identifiers with additional meaning 🎉.

There is already similar concepts like one that ruleguard uses and a lot more.

Just a little question about swc: If I use swc-loader as a babel-loader replacement, what are the trade-offs excluding the compilation speed?