| 07:04 | <rkirsling> | hasn't this dude already been banned from other repos or something |
| 07:12 | <ljharb> | not that i know of. altho bear in mind this is public and they do read these logs. |
| 07:17 | <rkirsling> | sigh |
| 07:27 | <ryzokuken> | Oh wow, that's quite a thread. |
| 07:54 | <ljharb> | anyone who prefers not to engage in that thread, but has concrete suggestions, is more than welcome to DM them to me and i'll update the PR |
| 09:14 | <nicolo-ribaudo> | I agree with the intention of that PR, but I don't think it will accomplish much. As far as I know, core-js is the only polyfill that has ever been mentioned in "this will break the web" discussions (because it's super popular?), and zloirock is free to ignore the "only stage 3" recommendation. |
| 09:16 | <nicolo-ribaudo> | Maybe something better would be to suggest "early stage polyfills should never rely on feature detection, and unconditionally install the polyfilled version": this highly reduces the chances of "breaking the web" because changes to the environment don't affect how the polyfill behaves |
| 09:17 | <nicolo-ribaudo> | It would become similar to transpilers, that cause way less problems because they unconditionally transform the code regardless of what's supported at runtime. (But transpilers are on a whole other level anyway, because they work ahead of time) |
| 16:08 | <ljharb> | es5-shim and es6-shim have come up in those discussions too, but not for this reason, true |
| 16:09 | <ljharb> | everyone is free to ignore the recommendation, thats why it’s a recommendation - but he used the process doc as a justification for publishing polyfills for stage 1 features. I don’t want anyone else thinking it’s ok in the future, even if it has no impact on his choices. |
| 17:54 | <jschoi> | Maybe something better would be to suggest "early stage polyfills should never rely on feature detection, and unconditionally install the polyfilled version": this highly reduces the chances of "breaking the web" because changes to the environment don't affect how the polyfill behaves |
| 17:54 | <jschoi> | Even production code can safely (safe = doesn’t break if a proposal changes) mutate globals however it wants, as long as the mutation is not conditional on feature detection. The library-publication thing might be a non sequitur, in that production code that conditionally mutates globals (even without relying on a library) is unsafe, and libraries that mutate globals unconditionally without relying on feature detection are safe (as far as I can tell). |
| 17:55 | <jschoi> | I submitted some code-review suggestions to that effect. |
| 18:01 | <justingrant> | One thing we did (and are still doing) with Temporal was to emit a console log warning when the polyfill was loaded to remind folks not to use it in production. Not sure if this makes sense to be a general recommendation, but IMHO it's a helpful signal that's highly visible without preventing usage. Should something like this also be recommended in the doc, esp. for early-stage polyfills? |
| 18:03 | <justingrant> | I wasn't suggesting a warning is an alternative to whatever's being argued about in that thread; it's orthogonal. |
| 18:04 | <jschoi> | Jack Works mentioned doing that too for their Number.range implementation in https://github.com/tc39/process-document/pull/33#issuecomment-997147848. |
| 18:10 | <Mathieu Hofman> | The problem with unconditionally mutating or using a global is that it has to be pervasive. Imagine the following scenario: a feature has reached stage 3-4 with significant changes from stage 1-2, a large code base uses a stage 1-2 version of a feature and unconditionally mutates the global. A dependency uses the same feature, but has been updated to leverage the stage 3-4 so it conditionally uses the feature if available or fallsback to a bundled non global modifying shim. Unless the feature detection is thorough (not simple presence test), the dependency will break. Arguably this is only a problem when you explicitly update your dependency without updating your application code base, or the dependency is dynamically updating. This kind of issues somewhat happened with promises. |
| 18:11 | <jschoi> | That is true. Interoperability with community precedent was a large inertial force there, although it shaped the feature since its early stages of planning. |
| 18:13 | <Mathieu Hofman> | That said, I agree we should be recommending against conditional global mutation or usage before stage 3. |
| 18:16 | <Mathieu Hofman> | Then early adopters need to be conscious of the dependencies they have and make sure if their application adopts a feature early they need to follow updates to the feature or risk compatibility problems when updating their dependencies. |
| 18:20 | <Mathieu Hofman> | Stage 3 is a little murky tho. There is always a risk the API shape will break during that stage. The bar is higher for these changes but they do happen. |
| 19:15 | <ljharb> | They can happen after stage 4 too. The issue is risk, not certainty. |