Typescript: Ability to patch/overwrite missing/wrong declarations

Created on 7 Jul 2018  路  8Comments  路  Source: microsoft/TypeScript

Search Terms

correct wrong declaration, fix declaration, overwrite module declaration, fix module type

Suggestion

Sometimes we encounter an npm module with missing declarations and incorrect declarations in its types file. Wish we have this ability patch/correct its declaration for temporary using before PR a patch and have it's released.

Current behavior & Workaround

Consider this situation, module moduleWithIssues indeed exports itemExistedWithoutDeclaration but its declaration file doesn't contain it, and has a incorrect declaration itemWithWrongDeclaration

import {
    foo, bar,
    itemExistedWithoutDeclaration,   // report 'itemExistedWithoutDeclaration' doesn't exist
    itemWithWrongDeclaration
} from 'moduleWithIssues'

// 'itemWithWrongDeclaration' is number type but declared as string, TS report type error
console.log(Math.abs(itemWithWrongDeclaration))

At present, I found a workaround is adding a local module declaration for itemExistedWithoutDeclaration and assert itemWithWrongDeclaration as its correct declaration

import { foo, bar, itemExistedWithoutDeclaration, itemWithWrongDeclaration } from 'moduleWithIssues'

declare module 'moduleWithIssues' {
  const itemExistedWithoutDeclaration: number
}

const itemCorrected: number = itemWithWrongDeclaration as any

It works in *.ts file but not in *.d.ts file. An idea patching solution should be re-declare some items of moduleWithIssues in a *.d.ts file in the project. like below:

// interfaceInProject.d.ts
declare module 'moduleWithIssues' {
  const itemExistedWithoutDeclaration: number
  const itemWithWrongDeclaration: number
}

unfortunately this patch module will shadow original module declaration of moduleWithIssues package.

import { foo, bar, itemExistedWithoutDeclaration, itemWithWrongDeclaration } from 'moduleWithIssues'

foo and bar are reported non-existent.

Checklist

My suggestion meets these guidelines:

  • [x] This wouldn't be a breaking change in existing TypeScript / JavaScript code
  • [x] This wouldn't change the runtime behavior of existing JavaScript code
  • [x] This could be implemented without emitting different JS based on the types of the expressions
  • [x] This isn't a runtime feature (e.g. new expression-level syntax)
Needs Proposal Suggestion

Most helpful comment

Maybe we need a way to partially change declarations. Many patched declarations are not very correct.

All 8 comments

It seems like the current behavior is actually ideal, because otherwise you'd have no way to remove an incorrect declaration?

Maybe we need a way to partially change declarations. Many patched declarations are not very correct.

Any news? I also want to override incorrect declaration of document.open (lib.d.ts)
Because this is wrong typing

open(url?: string, name?: string, features?: string, replace?: boolean): Document;

correct is:

open(url: string, name: string, features: string): Window;
open(type?: string, replace?: string): Document;

https://developer.mozilla.org/en-US/docs/Web/API/Document/open

No news

This really is an annoying limitation. Eg. relay-compiler just updated from version 6 to 7, so while I tried to update the relay-compiler-language-typescript plugin I needed to modify the existing generate function on an interface (in definitelytyped), to add another parameter to it. Instead of being able to make a local @types/relay-compiler file and make the override there, I have to use give the interface another name and use that throughout the code. Logically thinking you should be allowed to override from local definition file.

In my case, the @types/chai library declares:

interface Object {
  should: Chai.Assertion;
}

And this infection affects how I use elasticsearch (that actually has should properties). I wish I could just force the Object interface back to its default state.

I'm not sure if this is a correct topic, but I'm having related issues:

typeorm module

export declare function Entity(options?: EntityOptions): Function

local global.d.ts

import * as typeorm from 'typeorm'

declare module 'typeorm' {
    export function Entity(options?: typeorm.EntityOptions): ClassDecorator;
    export function Entity(name?: string, options?: typeorm.EntityOptions): ClassDecorator;
}

Doesn't work:
image

UPD:
nvm, it just miraculously works now

nvm, it just miraculously worked now

Sometimes when working with changes on .d.ts files, restarting the TS Server fixes the issues, maybe that was your case?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bgrieder picture bgrieder  路  3Comments

remojansen picture remojansen  路  3Comments

jbondc picture jbondc  路  3Comments

dlaberge picture dlaberge  路  3Comments

siddjain picture siddjain  路  3Comments