Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to patch/overwrite missing/wrong declarations #25495

Open
4 tasks done
zheeeng opened this issue Jul 7, 2018 · 11 comments
Open
4 tasks done

Ability to patch/overwrite missing/wrong declarations #25495

zheeeng opened this issue Jul 7, 2018 · 11 comments
Labels
Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. Suggestion An idea for TypeScript

Comments

@zheeeng
Copy link

zheeeng commented 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)
@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. labels Jul 9, 2018
@RyanCavanaugh
Copy link
Member

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

@zheeeng
Copy link
Author

zheeeng commented Jul 9, 2018

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

@sirian
Copy link
Contributor

sirian commented Oct 9, 2019

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

@RyanCavanaugh
Copy link
Member

No news

@sorenhoyer
Copy link

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.

@villasv
Copy link

villasv commented 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.

@GrayStrider
Copy link

GrayStrider commented 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

@AlexandreMPDias
Copy link

AlexandreMPDias commented 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?

@cqh963852
Copy link

cqh963852 commented 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

@Aex12
Copy link

Aex12 commented 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.

@okko
Copy link

okko commented 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
Labels
Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

10 participants