TS definitions support?

Is your feature request related to a problem? Please describe. It’s almost a universal expectation for modules to have types so they can be used in a TS application.

Describe the solution you’d like If you are coding in TS, ship with declaration: true but you can also add it separately to https://github.com/DefinitelyTyped.

Describe alternatives you’ve considered I will have a go at creating something and will let you know when I have something.

Additional context No.

[Enteee]

I am not quite sure which return statement you mean, but the return statement of parse exposed by the module is here which really just forwards the returned parsed tree according to the parsing expression grammar. The actual parser is here, but since that’s all auto generated you don’t want to look at that.

For your purpose it’s probably best if you have a look at:

• the parsing expression grammar
• all the different types
• the formatters (Note: The default formatter just does a return JSON.stringify(..). No magic there)

In case you need examples, there is a wealth of them in the test/fixtures directory.

[Enteee]

Are the possible options the ones listed here and listed here?

It’s both. The option object will be forwarded to the generated parser. And also to the Tracer . I found that the two options don’t intersect and both silently ignore unknown options, therefore I merged the two in one object. I could actually really improve the documentation around that.

What data types are expected from the allowedStartRules and plugins properties?

Those are both options for the parser generator, not the parser itself. The supported options are documented here. But I would actually not expose startRule to the user, since that will almost always break the parser.

Which means what I would expose and document in the type is the following (mostly tracer options)

• verbose
• hiddenPaths
• useColor
• showTrace
• maxSourceLines
• maxPathLength
• matchesNode