Edit: unfortunately, this seems to be a JNI bridge to the Rust code in SWC, I was hoping for a JVM-native solution.
> 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.
HTH1 - https://github.com/antlr/grammars-v4/blob/master/javascript/...
Why Antlr is not the one? Hope the following blog I wrote may explain.
https://blog.caoccao.com/hello-swc4j-goodbye-antlr-f9a63e45a...
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...
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.