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
In 0.20, TypeDoc relies on the type checker to get exports - this works fine for the majority of TypeScript projects, but has resulted in worse support for legacy common JS projects that do bad things like this:
export=function(){}// 1export={ a, b, c,}// 2export=1// 3typeZ=1export=Z// 4functiona(){}namespacea{}export=a// 5
Suggested Solution
This is somewhat tricky to solve - # 2 above can be handled nicely by just "lifting" the "export=" symbol's properties so that they are documented under the parent module, but this breaks other cases.
# 1 and # 5 can probably be handled by setting the "signatures" property on the module...
But # 3 and # 4 are an extra level of horrible. The first should really be documented as a variable and the second as a type... I want to believe that people wouldn't do this, but...
The text was updated successfully, but these errors were encountered:
This gets worse! In JS, export= doesn't mean that other stuff can't be exported. #1476.... if you're using this. Please do your users a favor and give them a named export.
I expected a lot more interest in this - but am quite happy it's seen effectively no activity, since actually implementing this would make TypeDoc's already complicated "getExports" function much worse. I'm going to close this as not planned.
Search Terms
module.exports, export assignment, export=
Problem
In 0.20, TypeDoc relies on the type checker to get exports - this works fine for the majority of TypeScript projects, but has resulted in worse support for legacy common JS projects that do bad things like this:
Suggested Solution
This is somewhat tricky to solve - # 2 above can be handled nicely by just "lifting" the "export=" symbol's properties so that they are documented under the parent module, but this breaks other cases.
# 1 and # 5 can probably be handled by setting the "signatures" property on the module...
But # 3 and # 4 are an extra level of horrible. The first should really be documented as a variable and the second as a type... I want to believe that people wouldn't do this, but...
The text was updated successfully, but these errors were encountered: