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

Do not report excess property errors on spread #19775

Closed
mhegazy opened this issue Nov 6, 2017 · 8 comments
Closed

Do not report excess property errors on spread #19775

mhegazy opened this issue Nov 6, 2017 · 8 comments
Assignees
Labels
Bug A bug in TypeScript Fixed A PR has been merged for this issue

Comments

@mhegazy
Copy link
Contributor

mhegazy commented Nov 6, 2017

The result of a spread operator should not contribute to the excess property checks. only the properties listed in the object literal should be checked. i.e.:

declare var x: { a: number };

var y: { b: number } = { ...x, b: 0 };  // no errors on x, but should be OK
var z: { b: number } = { ...x, b: 0, c: 1 };  // c is excess
@mhegazy mhegazy added the Bug A bug in TypeScript label Nov 6, 2017
@mhegazy mhegazy added this to the TypeScript 2.7 milestone Nov 6, 2017
@lee-alexander
Copy link

Why is this a bug? I'm using this to get excess property checking to work when assigning an object of one type to another.

const a: TypeA;
const b: TypeB = a; // does not do EPC
const b: TypeB = {...a}; // does EPC

Are there any other workarounds to get EPC when you aren't using object literals?

@mhegazy
Copy link
Contributor Author

mhegazy commented Nov 8, 2017

Why is this a bug? I'm using this to get excess property checking to work when assigning an object of one type to another.

cause the error here is not correct really. types are open in TS, so you can easily defeat the check here, and you do not get the error elsewhere either.. e.g.

const x = { a: 0 , b: 0 } ;
const y : { a: number } = x; // no error
const z: { a : number } = { ...x } // error.. why?

@lee-alexander
Copy link

Makes sense that this inconsistency should be fixed. Is there any workaround to force excess property checking in the case when you do want it?

@mhegazy
Copy link
Contributor Author

mhegazy commented Nov 8, 2017

Is there any workaround to force excess property checking in the case when you do want it?

This is tracked by #12936

@robyoder
Copy link

We're running into this issue. I'm confused by your original comment though.

// no errors on x, but should be OK

Did you mean it does error on x?

@mhegazy
Copy link
Contributor Author

mhegazy commented May 10, 2018

the contents of x are not checked for excess properties...

@mhegazy mhegazy modified the milestones: TypeScript 3.0, TypeScript 3.1 Jul 2, 2018
@sandersn sandersn added the Fixed A PR has been merged for this issue label Aug 30, 2018
weswigham added a commit to weswigham/TypeScript that referenced this issue Oct 9, 2018
weswigham added a commit that referenced this issue Oct 17, 2018
* Unify JSX Call Checking Codepaths

* Add tests for fixed issues

* Fix lint, move all error checking into the only-run-once resolveSignature call

* Remove unused (unreachable?) code path

* Consolidate a little more duplicated logic into signature checking

* Fix #19775 a bit more

* Cosmetic changes from CR
@ktalebian
Copy link

ktalebian commented Dec 13, 2019

@mhegazy I have a question/concern about this. If using the spread operator is not going to report excessive property checks, this makes the new object dangerous do use.

For example, you can have a const newObject: NewType = { ...oldObject } and later, for instance, POST this parameter to a service, thinking you are only sending over NewType properties, but in fact you are also sending over some other properties that you are not aware of.

@robyoder
Copy link

robyoder commented Dec 14, 2019

@ktalebian this behavior is not unique to the spread operator. If you changed your example to just const newObject: NewType = oldObject it would work the same way.

As mentioned above, types are open in TypeScript. This is a design decision. But there’s a proposal (#12936) for the behavior you’re looking for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Fixed A PR has been merged for this issue
Projects
None yet
Development

No branches or pull requests

5 participants