Ability for ES module to be declared as an `any` type either via its text or via the compiler API during resolution

[dsherret]

Suggestion

With CJS, it's possible to define a module as an any type by writing:

var x: any;
export = x;

An issue is that Deno has been relying on this as a way for it to treat dependencies without types as an any type in ESM. So, the dependency has no types and Deno goes "that's fine... just use this any type, but if you want types then add a directive that specifies them". Now that we support CJS and ESM this has gotten more complicated (ex. #51321) and it would be nice to have a blessed way of doing this with esm so we can remove this code.

🔍 Search Terms

• "any type" module

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I have no idea what the text of the module could look like (declare module;?). Maybe instead this would be specified on ts.ResolvedModule or a certain kind of object returned when resolving modules to say "this is an any type". Then that module becomes represented as a non-global ambient module internally by TypeScript.

When I previously mentioned this problem on Discord, it was recommended to me that we should inject ambient modules like declare module "npm:three";. I do not believe it would be possible for us to inject ambient modules. Ambient modules have the huge downside of being global and in Deno the referrer is important for figuring out how specifiers resolve (ex. someone could use scopes in an import map to cause a specifier to mean one thing one place and then mean another thing a different place).

📃 Motivating Example

See below.

💻 Use Cases

It would be used in Deno for the runtime to mark modules as an any type so the user can use them without type checking where anything can be imported (and preferrably also re-exported) from them. We already do this, but in a non-ideal way.

Resolving this issue would close #51099 and #51136.

Thanks for considering!

[andrewbranch]

Initial impressions:

This sounds like a huge footgun to me. A require of a module that exists will always succeed, and return the manifest value that was module.exports = in the target. It makes sense for that value to have a type, and if the type is any, then consumer beware. This is just fundamentally different from ESM (I know I’m not telling you any new information by the way, just laying out how I think about it). Importing named exports from an ESM module is not analogous to destructuring members of an object type. The imported names have to exist on the exporting module or else any ESM loader I know of will fail.

At a low level, the request doesn’t fit with the way we actually represent modules. We don’t say that the module has some type, and when you import from it, you’re just accessing a member of that type. We say that the module has some exports, and those exports have a type. So in the case of a CJS module that did an export = resolving to something that’s any, we have a module with one export, which happens to be the special export= export which is aliased to another symbol, which has the type any. This is subtly different from saying that the module has the type any. With this mental model, it’s easier to see why in ESM land, there’s nothing that could make your request work.

Obviously, it would be possible to implement something like this as a special case, but hopefully this explanation makes it clear that this might be a bigger departure from the architectural model we have than it sounds like.

It sounds like what you really want is more like what happens when module resolution finds a JS file and no typings, but settings don’t allow analyzing the JS for type info (whether because allowJs is off or the file is in node_modules and maxJsNodeModulesDepth or whatever isn’t bumped up). In that case, we don’t even say that we have a module record; an implicit any just propagates from any attempted usage of it:

If you were able to leverage module resolution to do this rather than being able to declare that some module exists but say that its shape is any, would that work?

[weswigham]

You'd think, perhaps, that something like this:

// @filename: mod.d.ts
declare module "any dummy module name";
// @filename: any.ts
export * from "any dummy module name";
// @filename: usage.ts
import {haha_whatever} from "./any";

would already work, but we issue an error on the haha_whatever import precisely because a module whose shape is any, which is what declare module "any dummy module name"; makes, actually has no named exports as far as we're concerned.

[dsherret]

Thanks for discussing this! I'm going to close this issue. I think in Deno we need to look into ways of reforming this because it often confuses users when things just resolve to any.