[Feature Request] allow declare untyped path of typed module

[bluelovers]

Suggestion

🔍 Search Terms

declare untype 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

📃 Motivating Example

install @types/semver

global.d.ts

declare module 'semver/internal/parse-options'
{
	function parseOptionsOrLoose(options: Options): boolean | Options;

	export = parseOptionsOrLoose
}

💻 Use Cases

use for some typed module isn't have type everything

[andrewbranch]

I don’t really understand what the suggestion is. Can you provide more info?

[bluelovers]

• untyped meam it didn't have .d.ts
• typed meam it have .d.ts

1. if semver module only typed semver
2. if semver/internal/parse-options is untyped but it is exists file

allow we declare semver/internal/parse-options

declare module 'semver/internal/parse-options'
{
	function parseOptionsOrLoose(options: Options): boolean | Options;

	export = parseOptionsOrLoose
}

make import parseOptionsOrLoose from 'semver/internal/parse-options' is typed module

import parseOptionsOrLoose from 'semver/internal/parse-options'

// @ts-expect-error
parseOptionsOrLoose(number)

[andrewbranch]

Can’t you already do that?

[bluelovers]

[andrewbranch]

Ensure the file you’re in is a .d.ts file, not a .ts file. There’s a difference between a module augmentation and an ambient module declaration. You may also have to move the import declaration inside the module declaration block; I forget.