Repository navigation
Backward compat issue with non enumerable properties #38958
Description
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
Activity
RyanCavanaugh commentedon Jun 5, 2020
Which properties? Class properties? Are they initialized? What are your compiler settings?
AviVahl commentedon Jun 5, 2020
He's probably referring to #32264 which was documented in the release notes as a breaking change.
David Catuhe (@deltakosh) consider using
Object.getOwnPropertyNameswhen 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-objectRyanCavanaugh commentedon Jun 5, 2020
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 commentedon Jun 5, 2020
well it was a fast discussion :)... We cannot use
for inanymore (only 617 entries in babylon.js, should be easy)AviVahl commentedon Jun 6, 2020
All those
for inusages would break once you've dropped es5: https://jsbin.com/wizededujo/edit?js,consoleThe previous inconsistency in behaviour between es5 and es2015 targets was way more problematic, and I personally appreciate this change.
deltakosh commentedon Jun 6, 2020
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 commentedon Jun 6, 2020
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 commentedon 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