Hello @BinaryMuse and other contributors 😄

Context

I am creating a set of re-usable and modular Toml related tooling in here.

One of the first modules is a Toml to Syntax Tree parser.

How this could benefit the Toml-Node project

The Toml to Concrete Syntax Tree parser could be evaluated for re-use as the parser for this repo's Toml to Json compiler. So instead of implementing both a parser and a compiler in this repo. Toml-Node would only implement a (to Json) compiler using a Syntax Tree Visitor.

Pros

• Let someone else deal with aligning to the specifications 😄 .
• Toml 0.5 support.
  • Will solve Support for TOML 0.5.0? #50
• I estimate (potential) for around two orders of magnitude higher performance than Toml-Node.
• Try out the benchmark.
• Just an estimate, Depends on how complex the compiler is relative to parsing...
• Will solve toml parsing is too slow #39

Cons

• Early work, expect some bugs.
  • But those should be ironed out quickly as the Toml spec is very simple.
• Larger library size (including deps) as the Chevrotain Parsing Toolkit runtime used is: 146K/B minified.
  • See: https://cdn.jsdelivr.net/npm/chevrotain@4.2.0/lib/
• No Streaming support (yet).
  • Will hopefully exist at a later time (but likely not soon).
• No longer a dependency free library.
• Bundling of Chevrotain based parsers must be done carefully due to reliance on
  Function.prototype.toString.
  • but this can be fully mitigated transparently from end users.

Summary

This has a potential to improve both the performance and alignment to newest spec of Toml Node, but with the cons described above.

@BinaryMuse could this be of interest to Toml Node?

Cheers.
Shahar.