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

Option 'strictPropertyInitialization' cannot be specified without specifying option 'strictNullChecks' #24716

Closed
marcomura opened this issue Jun 6, 2018 · 7 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@marcomura
Copy link

Upgrading from 2.8.1 to 2.9.1, I'm now getting the error in the title.
Why strictPropertyInitialization now can't be specified without strictNullChecks? Is it a bug?

@a-tarasyuk
Copy link
Contributor

@marcomura I think, it is not a bug, see #23659

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jun 6, 2018
@RyanCavanaugh
Copy link
Member

SPI does nothing if SNC isn't on, so this warning is to tell you that you're not doing what you think you are

@marcomura
Copy link
Author

marcomura commented Jun 6, 2018

Why strictPropertyInitialization should require strictNullChecks?

class C {
    foo: number;
    bar = "hello";
    baz: boolean;
    //  ~~~
    //  Error! Property 'baz' has no initializer and is not assigned directly in the constructor.
    constructor() {
        this.foo = 42;
    }
}

Without stringNullChecks, I can solve the error explicitly assigning undefined to baz.

@marcomura
Copy link
Author

Ping on this :)

@mhegazy
Copy link
Contributor

mhegazy commented Jun 11, 2018

Please see what --strictNullChecks really mean at https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript

@marcomura
Copy link
Author

That's why I can't see its relation with --strictPropertyInitialization

@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

5 participants