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.

[mootari]

As a more general question, could the type drift be avoided by moving the declarations into the code as JSDoc annotations and generating the .d.ts files from those? Or would the added verbosity be too much of a tradeoff?

[dummdidumm]

Related: This also removed all of the internal type definitions of the Parser class. I think it makes sense to not bloat the public types with it, also considering it's somewhat private API, but it makes live much harder for plugin authors. Would you open to having a separate acorn/private-types (or similar) types-only export that provides these type definitions with the caveat that these may change at any time as they are not subject to semver?

[marijnh]

I don't want to maintain such a set of type declarations myself, but if somebody wants to offer it as their own project, I'm sure that's helpful to a lot of people.

(Also, it's not that we don't provide any stability of internal method compatibility inside major releases. We make an effort to not break things, when possible, and have historically put off major changes to these interfaces to coincide with major releases.)