Open billti opened 6 years ago
For future investigation, here's a small repro (I think):
// @Filename: ex.d.ts
import * as _d3 from './d3'
declare global {
const d3: typeof _d3;
}
// @Filename: d3.ts
interface DefaultArcObject {
a: number
}
// @Filename: use.js
/** @type {d3.DefaultArcObject} BROKEN */
var x;
/** @type {import('./d3').DefaultArcObject} OK */
var y;
Note that d3 has export as namespace d3
now so the original example should work.
I hit this while writing an electron app using
checkJs
where you can bothrequire
code in (thus making your file a module), and there may also be script tags loading code in the HTML for the app. For example, by main page has the below as it is using D3. Thus the 'd3' object is available globally.Trying to use the global D3 in my
app.js
however results in the error'd3' refers to a UMD global, but the current file is a module...
, so I've added the common workaround below to avoid this via a .d.ts file.When the above .d.ts code is present (and only when), JSDoc gives an error on trying to use types from the namespace, i.e. the below code
Results in the error
Namespace '"./@types/d3/index".d3' has no exported member 'DefaultArcObject'.
Yet the below TypeScript continues to work fine:The below also continues to work fine in JavaScript, but is kind of ugly and a pain to have to repeat (especially if you need to use a lot of type arguments)
Personally I'd rather not have to do the .d.ts workaround at all and just be able to use the
d3
global in my modules (see the highly controversial #10178). That not being the case, JsDoc should be able to access the types still with the workaround in place.