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

Support disabling weak type checking #16968

Closed
smhc opened this issue Jul 6, 2017 · 3 comments
Closed

Support disabling weak type checking #16968

smhc opened this issue Jul 6, 2017 · 3 comments

Comments

@smhc
Copy link

smhc commented Jul 6, 2017

TypeScript Version: 2.4.1

Expected behavior:

Can compile projects using third party dependencies that have not been upgraded to support strict weak type checks in typescript 2.4.1.

Actual behavior:

Projects that depend on third party libraries that have 'weak type' errors cause compilation errors. The proposed workarounds are not possible when the type definitions reside in third party code.

Proposed Solution:

A flag to disable strict weak type checks.
Even better would be the ability to enable/disable similar strict checks for third party libraries (node_modules) selectively.
The dependency may very well have a bug or poor definition, and it may or may not get fixed. But even if it does get fixed, the fix may be in a version that is impractical to upgrade to.

I hit the issue with protractor and was fortunately able to upgrade to a version that didn't have regressions. I am now hitting the problem with ag-grid: ag-grid/ag-grid#1745
This one doesn't seem like a 'bug', but rather a poor definition. If it is fixed, I may not be able to upgrade to the version it is fixed in.

@smhc
Copy link
Author

smhc commented Jul 6, 2017

Some further discussion of this is located here: ag-grid/ag-grid#1708

I thought weak type 'implements' may still be useful for code like the below. However typescript doesn't actually pick this up as an error. I think it would be helpful if it did, and weak type implements should be allowed if so.

// Library code

interface IDisposable {
    // implement if you want custom dispose code
    dispose?: () => boolean;
}

class DefaultThing implements IDisposable {
    // doesn't require custom dispose, but extenders should implement it correctly if they do
    public work(): number {
        return 0;
    }
}

// Project code

class MyThing extends DefaultThing {
    // want to inherit 'work()', but also the type checking of 'dispose(): boolean'
    public dispose(): string {  // want an error here
        return '';
    }
}

@RyanCavanaugh
Copy link
Member

The referenced issue has an explanation from me of what you should be doing in that case.

@smhc
Copy link
Author

smhc commented Jul 7, 2017

Closing this issue as it is discussed elsewhere.
Will wait to see if many others are hit by the same problem that prevents being able to upgrade before following it up further.

@smhc smhc closed this as completed Jul 7, 2017
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants