Latest release is missing type definitions

[dummdidumm]

Acorn 8.11.2 seems to have shipped with broken type definitions. Some methods like isIdentifierStart are missing from d.ts files (they exist in the actual JS code though).

[marijnh]

The internal/plugin interfaces are not part of the new type definitions. The old ones accidentally had some of them in there. What kind of thing are you doing that you need isIdentifierStart?

[dummdidumm]

We're using isIdentifierStart and isIdentifierChar inside Svelte's template parser to read identifiers (checking when they start and when they end)

[marijnh]

Are you able to switch to a \p-based regexp ([\p{L}\p{Nl}$_][\p{L}\p{Nl}$\p{Mn}\p{Mc}\p{Nd}\p{Pc}]*) in your parser, or do you target engines that don't have a \p yet?

[RReverser]

@marijnh I believe it can be even simpler with something like /^[\p{ID_Start}$_][\p{ID_Continue}$]$/u.

[nzakas]

The internal/plugin interfaces are not part of the new type definitions.

I'm assuming the reason for this is to make life easier for people who are simply using Acorn as-is, avoiding showing a hundred methods in their editor.

But for plugin authors, this makes creating a plugin that will satisfy tsc significantly more work. There's nothing out of the box that will just work even with the simple example in the README.

Would it make sense to add another class that is targeted at plugin authors and then add the type definitions to that? Something like:

class PluginParserBase extends Parser {}

[marijnh]

The thing is that no one has really done the work to specify this huge internal plugin interface (which is pretty much 'every property and method on the parser object' plus some odd exports). That might be useful work, but I personally am the only active maintainer at the moment and this is not a focus for me, so I'm not sure when or by who it would be done.

Also, is there any TypeScript mechanism that could allow people to opt into an alternative or extended set of types like this without too much kludges? Was your idea to just have people extend some dummy wrapper class that is part of the main types?

[nzakas]

That might be useful work, but I personally am the only active maintainer at the moment and this is not a focus for me, so I'm not sure when or by who it would be done.

I could take a stab at it, if you'd like. I've essentially had to do this work for the plugin I'm working on.

Also, is there any TypeScript mechanism that could allow people to opt into an alternative or extended set of types like this without too much kludges? Was your idea to just have people extend some dummy wrapper class that is part of the main types?

I'm just learning the ins and outs of TypeScript, myself, so I'm not 100% sure. The complexity, as far as I can tell, is that plugins received a constructor to extend as an argument. As a result, TypeScript wants that type to be defined as class-like, which the current Parser type fails because it doesn't have a public constructor. If Parser had a public constructor, then we might be able to export an interface that people could mix in to their subclass with the additional properties and methods. I'd need to prototype that out to verify.