Open kevinpschaaf opened 1 year ago
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:
input:
const foo = Symbol('foo');
export class MyElement extends HTMLElement {
[foo]() {
console.log('foo called');
}
}
export foo as bar;
manifest:
{
"path": "foo.js",
"exports": [
{
"kind": "js",
"name": "bar",
"declaration": {
"name": "foo"
}
}
],
"declarations": [
{
"kind": "class",
"members": [
{
"kind": "method",
"nameReference": {
"package": "my-package",
"module": "foo.js",
"name": "bar"
}
}
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.