This works for one level of indirection to a local namespace-y thing, but what about an aliased namespacey thing? Eg

constmod=require("./mod.js")/***@typedef {string} T*/module.exports=mod

or, abusing a ts construct to do it locally,

namespacens{exportnamespaceinner{}}importmod=ns.inner/***@typedef {string} T*/module.exports=mod

mod's symbol will be an alias, and this will just patch the typedefs onto the alias symbol, and not the alias symbol's ultimate target, which, dollars to donuts, means it's going to effectively go missing without extra lookup logic in the checker, similar to what we used to have. 🥹

Even simpler, this also reproduces the problem.

functionf(){}/**@typedef {string} T */module.exports=f

Hm. So if the resolution of the LHS of a qualified name fails, we try to look it up with only one level of aliasing? This seems... weird? While this might work in some scenarios, ifgetExportsOfSymbol doesn't return the merged in aliases, declaration emit is going to struggle to figure out how to name these typedefs, as traversing the exports is how symbols are named. Basically, we'd like to interpret

/*** @typedef {number} Foo*/module.exports = name

as

export*fromname// even though this isn't a thing in ESM (yet)exporttypeFoo=number

I think if we want to handle this in a non-jank way, we need to bind amodule.exports = name in a file with typedefs not as an alias but instead as a (new?) namespacey symbol kind that has logic ingetExportsOfSymbol to merge together the typedef set and the resolved, late-bound alias's set. (Once again, a callback to the.cjsSymbolMerged logic we used to have)

I'm also honestly a lil unsure what a syntactically driven declaration emit for this is.

Maybe we just add support for parsing/checkingexport * from name in declaration files and actually do that transform on reparse? In theory it'll be added to esm alongside the module declarations proposal, probably.

I tried this in1cffb6e, but it results in just as many hacks, in the same places, as the previous commit. That's becauseexport * isn't callable, so I need the same kind of stop-in-the-middle hack to return the symbol of a function initialiser, plus an additional hack to look for and add call signatures when resolving members of theexport *.

So I reverted it. Can you come up with a way to improve the current hack? I think one-level resolution is fine even if not; commonjs usage is ossified and I think the support can be accordingly restrictive.

So I reverted it. Can you come up with a way to improve the current hack?

Honestly?1cffb6e but go a little bit farther - with slightly more accompanying checker complexity - rather than tossing it into theexport* symbol table member and fishing it out, make a new special symbol table member for cjs export assignments that does the whole "copy the whole target and add the other exports on, too" rigamarole on export table lookup, complete with custom conflict resolution logic. Unfortunately, it definitely doesn't behave like any other AST construct we have at present because it's anexport= and aexport* symbol all rolled into one (or perhaps a mutableexport=).

I think a lot of why the strada implementation feels jank isn't because of the weird expression binding, but rather is because of our refusal to handle it like it's its own thing and instead patching its' behaviors on top of the existing ones. I'd rather handle it explicitly as its' own thing through the whole process and lower my worries that we're either shoehorning it into something it's not quite equivalent to and breaking a bunch of legacy code (which is all this is here for! "new jsdoc code" is almost an oxymoron) or patching exceptions on in an ad-hoc way like we did in strada.

Or the other option is to loosen how we handleexport= internally to behave like the cjsmodule.exports= in strada - then it could be equivalent to that, I guess. There's honestly very little reason to disallow

export=classFoo{}exportconsta=1

in cjs-targeting typescript other than historic strictness and taste (since it transpiles to the same declarations we're checking on the input side here).