Swc4j: SWC for Java | Hacker News Reader

Swc4j: SWC for Java

github.com

70 pointsstefankuehnel17 comments

Oh my word, there may finally be a Typescript parser for the JVM? I have wanted this for the longest time, and it's been on my radar to take on as a project in the near future. If this is a reasonably complete parser, this will save me a ton of time. My use case is parsing Typescript type definitions.

Edit: unfortunately, this seems to be a JNI bridge to the Rust code in SWC, I was hoping for a JVM-native solution.

> My use case is parsing Typescript type definitions.

> Edit: unfortunately, this seems to be a JNI bridge to the Rust code in SWC, I was hoping for a JVM-native solution.

Maybe tree-sitter[0] TypeScript support[1] could do the trick?

  Tree-sitter is a parser generator tool and an incremental 
  parsing library. It can build a concrete syntax tree for a 
  source file and efficiently update the syntax tree as the 
  source file is edited.

HTH

0 - https://tree-sitter.github.io/tree-sitter/

1 - https://github.com/tree-sitter/tree-sitter-typescript

Tree sitter has a C runtime, and often a C scanner.

Right, that would be another native bridge solution.

See my peer comment for another option. :-)

If the tree-sitter runtime requirements are prohibitive and a pure JVM solution (IOW, no JNI) mandatory, then I'd recommend using antlr[0] with its representative grammar[1] as a starting point. See here[2] for more details.

0 - https://www.antlr.org/

1 - https://github.com/antlr/grammars-v4/blob/master/javascript/...

2 - https://github.com/antlr/grammars-v4/wiki

I'm the maintainer of swc4j. I had been using Antlr for many years, but was deeply disappointed by Antlr. So I created swc4j.

Why Antlr is not the one? Hope the following blog I wrote may explain.

https://blog.caoccao.com/hello-swc4j-goodbye-antlr-f9a63e45a...

I agree that the Antlr Typescript grammar is underwhelming, and I also agree with the difficulty of not having a well defined owner of the project to interact with. My main use case is parsing TS type definitions, and the grammar from the grammars-v4 repo doesn't parse anything starting with 'declare', which is pretty fundamental.

I get the sense that treesitter is more for syntax highlighting than for real parsing, since I raised this issue[0] a while ago and I don't think anyone's really interested in it (not really interested enough myself in tree-sitter to see if it can be fundamentally solved; solving it involves making almost all production rules in the grammar parametric over two booleans).

Admittedly I haven't tested the TypeScript treesitter grammar, but I'd be surprised if the issue is fixed there. I've put together a sample file[1] that demonstrates various cases of these context dependencies. If I remember correctly, Sublime's highlighter was the best at handling these cases out of various editors I tried, though it still failed at some of the ones at the bottom involving multi-line function expressions within object literal keys. GitHub/gist uses treesitter, so you'll notice that sometimes the "REGEX" and "DIVISION" blocks are inconsistently coloured, but a correct parser should associate a colour consistently to them. Not demonstrated here, but inserting a multi-line comment in a file that is parsed incorrectly will throw the entire thing off.

[0] https://github.com/tree-sitter/tree-sitter-javascript/issues...

[1] https://gist.github.com/Maxdamantus/a11b41675fcde25ffc9b7ef0...

Just curious as to why you would want that?

I want to use Typescript types to improve IDE support for a compile-to-JS language (ClojureScript).

I'm the maintainer of swc4j. I'd like to share some of my thoughts for your reference.

Before swc4j was born,

1. I was deeply disappointed by Antlr. My blog https://blog.caoccao.com/hello-swc4j-goodbye-antlr-f9a63e45a... explains why. 2. I could use Babel in Node.js on JVM (using another project Javet created by me) to meet the business requirements, but Babel's performance is 10x-100x worse than swc's. 3. There was nothing else better. 4. swc is one of the best solutions in front-end toolchain. It's well maintained. Its community is healty. It is being used by Node.js and Deno.

So I decided to try to embed swc in JVM. After a month of intensive development from scratch, swc4j was alive. In my opinion, its design has to be a genuine swc library bridged by JNI or other native interop mechanisms on JVM for the following reasons.

1. The dev cost of reinventing the wheels on JVM is unbearable to me. Tracking the JS / TS / JSX / TSX / ... specs from time to time requires a dedicated team. 2. The performance overhead is subtle. 3. The behavior is identical to the genuine swc. That brings confidence to the swc4j users.

Hope these make sense.

Thanks for the reply, I think your reasons make total sense for your use case and I was also underwhelmed by Antlr, or at least the TS grammar for it. But I don't need the vast majority of what SWC offers, I just need a type declaration parser - that seems like it should be much more tractable to keep up to date, especially since there's a massive test suite in DefinitelyTyped.

elide has a typescript layer for graaljs

What are some use cases for this?

Javascript bundling for Spring Boot applications?

Seeing this also https://news.ycombinator.com/item?id=42592524

Reply on news.ycombinator.com