Error when generating definition from javascript (error TS9006)

[llgcode]

Bug Report

Hi,
our goal is to generate definition from javascript files.It will be helpful for checking types and have completion.

Our workspace environmnent is a multi project that declare project dependencies using references property in tsconfig.

It is stopped in our case with this error TS9006: Declaration emit for this file requires using private name 'BaseClass'.

We couldn't find a satisfactory workaround.

Can we say that it is a limitation of typescript ?

Thanks

🔎 Search Terms

error TS9006: Declaration emit for this file requires using private name

Not sure if this is the same issue as #41672

🕗 Version & Regression Information

No regression. It is something that we started to work on.
The issue is reproducible with typescript 4.5.5 and 4.6.0-beta.

⏯ Playground Link

This minimal repo illustrate our case and highlight the issue:
https://github.com/llgcode/js-def-issue

💻 Code

declare module "deps/BaseClass" {
    class BaseClass {
        static extends<A>(a: A): new () => A & BaseClass;
    }
    export = BaseClass;
}

define("lib/ExtendedClass", ["deps/BaseClass"], 
/**
 * {typeof import("deps/BaseClass")}
 * @param  {typeof import("deps/BaseClass")} BaseClass 
 * @returns 
 */
(BaseClass) => {    
    
    const ExtendedClass = BaseClass.extends({
        f: function() {
            return "something";
        }
    });

    // Exports the module in a way tsc recognize class export 
    const module = {};
    module.exports = ExtendedClass
    return module.exports;
});

🙁 Actual behavior

ExtendedClass.js:1:1 - error TS9006: Declaration emit for this file requires using private name 'BaseClass' from module '"deps/BaseClass"'. An explicit type annotation may unblock declaration emit.

1 define("lib/ExtendedClass", ["deps/BaseClass"],
  ~~~~~~

🙂 Expected behavior

Generate the definition file.

[weswigham]

Right, so comment one: we don't really support AMD module wrappers in our input modules, afaik. I mean, we'll typecheck them as best we can, but they aren't specially recognized as defining or being modules or anything. (In fact, you'd have to write a amd-module triple-slash comment to tell us the module name if it's needed in any output). So with that out of the way, let's talk about what's going on here. We are trying to generate a module declaration file for ExtendedClass.js, because for some reason, we pick up the nested module.exports reference and see it as an indicator that the file is a module (?!? I thought we only detected these outside of function bodies...). I guess your comments indicate you know this and are exploiting it to your own ends. With that all explained, we come to the meat of the issue: Why is BaseClass not accessible? Turns out our declaration emit symbol accessibility checking logic can't currently detect that the target of an ambient module's export = should be considered accessible via said module. A relatively simple fix, now up at #47835

[llgcode]

Thanks @weswigham. :-)
What would be the right way to define an AMD module to have a definition generated in the right way?