Bradford C. Smith
Bradford C. Smith
It's not clear how we could polyfill this. It seems like any attempt would be imperfect at best. It doesn't really seem worth doing. We are willing to review a...
Would you be able to send us a pull request with the change you're asking for? We have no knowledge of registry.bazel.build. If supporting it is as simple as a...
@jzhan-canva, I'm sorry to say that I don't know how to submit the request you're talking about.
I realize it feels annoying to be forced to supply the second argument to `parseInt()`, but it avoids a footgun and leads to clearer (more explicit about what it's doing)...
Maybe some interested party could add a Peephole pass to remove an unnecessary second argument to `parseInt`. I don't think our core team is likely to prioritize doing that, though.
No, it's still required. If it were optional, the declaration would look like this. ``` * @param {number=} radix ```
For Closure Compiler: Steve Hicks is @shicks Also include @blickly and @concavelenz
This coding pattern is outside of the range of what we actively support. 1. Modules need to be defined with `goog.module()` and imported with `goog.require()` in order to be well...
The support for ES modules was certainly added. However, within google all the JS that closure-compiler sees uses `goog.require()` and `goog.module()` to define modules. So, if it breaks we won't...
I should also point out the compiler isn't designed to handle aliasing of global namespaces that are pseudo-exported via `globalThis`. This is the kind of non-standard coding pattern that we...