TS definitions support?

[ali-habibzadeh]

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]

Thank you for submitting this @ali-habibzadeh.

The project does currently not expose any types/interfaces. But I can see the advantage of parse and the formatters returning a strongly typed result.

I will have a go at creating something and will let you know when I have something.

That would be much appreciated! :+1: I will therefore leave this open for now and wait for more feedback and maybe input from others.

[geopic]

Are you still working on this @ali-habibzadeh? I'd be happy to take over if you're ok with that.

[Enteee]

@geopic thank you for your interest in this issue. Since I have not heard anything, I do think @ali-habibzadeh has abandoned this.

@ali-habibzadeh : Please correct me if I am wrong. @geopic : I would really appreciate your contribution.

[geopic]

I'll get started on it within a few days then, unless @ali-habibzadeh objects.

[Enteee]

Great, don't hesitate to ask questions if you have any. I'll be monitoring GitHub closely.

[geopic]

Hey @Enteee I have some questions about the options object for .parse. Are the possible options the ones listed here and listed here? What data types are expected from the allowedStartRules and plugins properties?

[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

[geopic]

I have another question about parse. In the Readme it says it return an AST but I can't find where the actual return statement is, can you show me where parse is getting its returned value from?

[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.

[geopic]

@Enteee Thanks for the help and taking time to link to some resources.

[Enteee]

Implemented with #33