You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This could be represented in the manifest by expanding the model for a class field's name to either be a string or Reference to a symbol's declaration. However, currently the name field for class members (currently defined on PropertyLike) is typed as a string and required, so a change to this type would represent a breaking change.
A (mostly?) backward compatible way to represent such class members could be to add an optional nameReference?: Reference field to ClassField and ClassMethod, which would be interpreted as a reference to a symbol's VariableDeclaration when present. Because name would still be required, it could be filled with a "display string" used for e.g. documentation viewers, e.g.:
"Mostly" because tools could possibly be using name for purposes other than display, in which case it's still wrong, and might be better to just make a breaking change to support it.
The text was updated successfully, but these errors were encountered:
References are still tricky... we need to give guidance here on whether this should point to the export of the module (yes) so that docs can resolve it to a public API member. It's the same with other references, just bears repeating, so that this works:
The manifest cannot currently describe class members whose name is defined using a symbol, which is valid JS and not uncommonly used:
This could be represented in the manifest by expanding the model for a class field's
name
to either be astring
orReference
to a symbol's declaration. However, currently thename
field for class members (currently defined onPropertyLike
) is typed as astring
and required, so a change to this type would represent a breaking change.A (mostly?) backward compatible way to represent such class members could be to add an optional
nameReference?: Reference
field toClassField
andClassMethod
, which would be interpreted as a reference to a symbol'sVariableDeclaration
when present. Becausename
would still be required, it could be filled with a "display string" used for e.g. documentation viewers, e.g.:"Mostly" because tools could possibly be using
name
for purposes other than display, in which case it's still wrong, and might be better to just make a breaking change to support it.The text was updated successfully, but these errors were encountered: