-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
ES6 and Object.defineProperties issue #3744
Comments
The compiler does not understand that Admittedly, it would be best if the compiler could understand the |
@ctjlewis thanks for your clarification, so it means closure ignores Object.defineProperties/Object.defineProperty ? Ok, i am working on three.js and i didn't want to change the code too much but looks like i have no choice to make it closure compatible. |
Yeah, I think we have had issues about this before, for this exact library and this exact situation. @lauraharker, @brad4d, does this issue (with the Some Googling gives me: |
If it's infeasible to update the actual property declaration to be a simple assignment, it would also work to declare the property separately. Something like |
How can More to the point though, As yet another option, if you're able to patch the code, you could replace the |
@nreid260 yeah, i know, it sounds strange, but it's very typical for three.js. Cycle deps everywhere ... I am about to give up adopting three.js to closure, despite the fact, only 260 warnings left (initially it was ~3000) ... thanks for your support ! |
Depending on what the warnings are, you could just |
Just want to add, the compiler recognizes properties creates by That distinction might feel arbitrary, but optimizations generally require less information about properties (usually just "does this name exist somewhere in the program?") so it's easier to add support. Recognizing them during typechecking is more nuanced. Additionally, optimization failure can cause runtime behaviour issues, so we need to be very conservative, and often silently cancel optimizations when something might be wrong. In contrast, typechecking failure is a compile-time problem, so we can make it more user visible, and defer to the user (via suppressions or annotations) when we get false positives. |
thanks, it works !
so isTest2 can be suppressed, but isTest is always undefined :(
|
lets say i have the following class:
and the following warning:
I have no idea what i do wrong, maybe i missed something ?
The text was updated successfully, but these errors were encountered: