Skip to content

Ability to patch/overwrite missing/wrong declarations #25495

Open
Open
Ability to patch/overwrite missing/wrong declarations#25495
Labels
Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.SuggestionAn idea for TypeScript

Description

@zheeeng
Zheeeng (zheeeng)
opened on Jul 7, 2018

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:

  • 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. new expression-level syntax)

Activity

  1. Ryan Cavanaugh (RyanCavanaugh)
    added
    SuggestionAn idea for TypeScript
    Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.
    on Jul 9, 2018

  2. RyanCavanaugh commented on Jul 9, 2018

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Jul 9, 2018
    Member

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

  3. zheeeng commented on Jul 9, 2018

    @zheeeng
    Zheeeng (zheeeng)
    on Jul 9, 2018
    Author

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

  4. sirian commented on Oct 9, 2019

    @sirian
    sirian
    on Oct 9, 2019
    Contributor

    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

  5. RyanCavanaugh commented on Oct 9, 2019

    @RyanCavanaugh
    Ryan Cavanaugh (RyanCavanaugh)
    on Oct 9, 2019
    Member

    No news

  6. sorenhoyer commented on Oct 26, 2019

    @sorenhoyer
    Søren Høyer (sorenhoyer)
    on Oct 26, 2019

    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.

  7. villasv commented on Jan 14, 2020

    @villasv
    Victor Villas (villasv)
    on Jan 14, 2020

    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.

  8. GrayStrider commented on Mar 28, 2020

    @GrayStrider
    GrayStrider
    on Mar 28, 2020

    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

  9. AlexandreMPDias commented on May 15, 2020

    @AlexandreMPDias
    Alexandre Dias (AlexandreMPDias)
    on May 15, 2020

    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?

  10. cqh963852 commented on May 3, 2021

    @cqh963852
    cqh (cqh963852)
    on May 3, 2021

    I am creating a library contains a class extends from eventemitter. I create declaration for some default event.

    I am looking a easy way to enhace the event types. So that my user can send the type event and listen the type event they like.

    It seems that this question is exactly what I was looking for.

    Screenshot from 2021-05-03 17-42-59

    It should be noted that if you want to modify the type, you need this library to have a corresponding export

    Screenshot from 2021-05-06 15-36-57

  11. Aex12 commented on Oct 4, 2022

    @Aex12
    Alex Caston (Aex12)
    on Oct 4, 2022

    I think something like this would be awesome. Fastify (a JS library with their own .d.ts declaration files) have some interfaces that could benefit from this. For example I'm trying to replace the FastifySchema interface that accepts unknown as values to actual schema definitions with TSchema from typebox, but I'm unable to replace their unknown types.

  12. okko commented on Mar 22, 2023

    @okko
    Okko Ojala (okko)
    on Mar 22, 2023

    One way to override module's incorrect index.d.ts:

    tsconfig.json

    {
  "compilerOptions": {
    "paths": {
      "module-with-issues": ["./typings/module-with-issues/index.d.ts"]
    }
  }
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.SuggestionAn idea for TypeScript

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions