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

Backward compat issue with non enumerable properties #38958

Closed
deltakosh opened this issue Jun 5, 2020 · 8 comments
Closed

Backward compat issue with non enumerable properties #38958

deltakosh opened this issue Jun 5, 2020 · 8 comments
Labels
Declined The issue was declined as something which matches the TypeScript vision Suggestion An idea for TypeScript

Comments

@deltakosh
Copy link

we (babylon.js team) are using a lot of properties and we need to enumerate properties for quite a few scenario (cloning, serialization, etc..)

Can we get a flag in the compiler to restore the previous scenario? This is a big breaking change for us?

Thanks a ton!

TypeScript Version: 3.9.5

Search Terms: Enumerable

Code no code related. We just need a way to preserve back compat while we migrate our code to a different pattern

Expected behavior: An option in the compiler to keep the properties enumerable

Actual behavior: Properties are not enumerable

@RyanCavanaugh
Copy link
Member

Which properties? Class properties? Are they initialized? What are your compiler settings?

@AviVahl
Copy link

AviVahl commented Jun 5, 2020

He's probably referring to #32264 which was documented in the release notes as a breaking change.

@deltakosh consider using Object.getOwnPropertyNames when you need to enumerate these properties. see: https://stackoverflow.com/questions/8024149/is-it-possible-to-get-the-non-enumerable-inherited-property-names-of-an-object

@RyanCavanaugh RyanCavanaugh added Declined The issue was declined as something which matches the TypeScript vision Suggestion An idea for TypeScript labels Jun 5, 2020
@RyanCavanaugh
Copy link
Member

If we add a flag we'll have to maintain it forever, so no. You can stay on 3.8 until you're ready to upgrade

@deltakosh
Copy link
Author

deltakosh commented Jun 5, 2020

well it was a fast discussion :)... We cannot use for in anymore (only 617 entries in babylon.js, should be easy)

@AviVahl
Copy link

AviVahl commented Jun 6, 2020

All those for in usages would break once you've dropped es5: https://jsbin.com/wizededujo/edit?js,console

The previous inconsistency in behaviour between es5 and es2015 targets was way more problematic, and I personally appreciate this change.

@deltakosh
Copy link
Author

Oh but don’t get me wrong I do appreciate it but I could also have appreciated a grace period. If we want to stick with latest versions, we have no option but do a large change in our codebase

@RyanCavanaugh
Copy link
Member

It's not like you couldn't have removed your code's dependence on a spec incompliance any time between now and whenever you wrote it. If we give you a flag now, then take it away later because it's a maintenance burden, all that does is change when in time you'd be unable to immediately upgrade.

@deltakosh
Copy link
Author

deltakosh commented Jun 6, 2020

Well first I was not aware of the incompliance until today. Furthermore even if I knew, I would have taken for granted that TS was setting the enumerable to true for me
More generally speaking, it could be useful to log a warning on the console to announce some incoming breaking changes of that magnitude

Great power, great responsibilities

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Declined The issue was declined as something which matches the TypeScript vision Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

3 participants