2025-12-01 [01:01:24.0231] Happy Monday, delegates! Just a few days before the notes deadline. that means reviewing the transcript of what you said and editing for accuracy, making sure links to proposals and slides are present and accurate, and recording a summary of the presentation/conversation as well as any decisions the committee reached at the conclusion. 2025-12-03 [11:04:33.0531] RCE in react server apparently arising from proto pollution gotta start encouraging people to put `delete Object.prototype.__proto__` at the top of all their files I guess [11:51:46.0623] Gotta suggest a CSP to remove it, it's normative optional anyway [11:59:32.0009] https://github.com/tc39/proposal-symbol-proto had something like that, although much more complex [11:59:38.0328] though in this case it was server-side [12:00:17.0121] (and node _does_ have `--disable-proto`, though no one uses it) [12:07:17.0697] If you could teach them to do this, you could teach them to not use objects as maps. Unfortunately, "we can teach them" as a strategy has never worked out once in my life. [12:07:35.0842] one of those things is a lot easier to teach! [12:08:32.0274] yeah, and JSON makes a lie of “don’t use objects for maps” every time. [12:17:04.0891] so does the performance of using objects for maps [12:54:20.0943] In the most recent meeting there was some advocacy for using objects as maps. Is this evidence against that? [12:56:23.0339] if you're going to use an object as a map, you _must_ use `__proto__: null` when creating it, that's all [12:56:55.0135] the language does this, e.g. in RegExp groups or `groupBy` [12:57:23.0154] However, JSON.parse, creator of many objects-as-maps, not so much. [12:58:04.0227] alas [12:59:51.0270] Where is JSON.parse2 [14:19:39.0176] seek the null prototype reviver [14:30:33.0896] that reminds me, there was a suggestion at some point to add an option `proto` parameter to `Object.fromEntries` [14:30:37.0171] though possibly it should accept only the value `null` [14:32:23.0475] just prepend your entries with `["__proto__", null]` 😜 [14:34:08.0063] ah yes, the bad old days of object initialization triggering setters from the prototype [15:11:27.0563] speaking of bad old days and object prototypes, does anyone else remember how in ES3 a named function expression (but not an anonymous function) would add an object with Object.prototype to the scope chain? [15:12:39.0609] * speaking of bad old days and object prototypes, does anyone else remember how in ES3 a named function expression (but not an anonymous function) would add an object with Object.prototype as its [[Prototype]] to the scope chain? [15:13:33.0663] at least one engine had actually implemented this literally (Opera I think?) and it was hilarious 2025-12-04 [13:59:29.0429] James M Snell jkup Richard Gibson Mathieu Hofman Andreu Botella rbuckton as people who expressed interest in improvements AbortController, want to make sure you've all seen https://github.com/whatwg/dom/pull/1425 [14:00:38.0805] which I am now seeing was discussed at WHATNOT this week; sad that I missed that. didn't get a notification for it being added to the agenda I guess. though per the notes nicolo-ribaudo participated at least [14:05:32.0081] * which I am now seeing was discussed at WHATNOT last week; sad that I missed that. didn't get a notification for it being added to the agenda I guess. though per the notes nicolo-ribaudo participated at least [14:05:47.0902] I missed this. Thanks for the ping! [15:39:24.0360] @danielrosenwasser:matrix.org Can I convince you to reverse https://github.com/microsoft/TypeScript/issues/51789? It’s trivial for you to implement, and prevents a lot of headache with https://github.com/tc39/proposal-string-dedent/issues/75 [15:41:17.0638] I don't follow, we won't be emitting to ES5 in the next version of TS, so freezing behavior will be the default [15:41:27.0541] For this version of TS [15:41:36.0228] Not everyone is going to immediately upgrade [15:41:50.0458] This is the last chance to fix a headache before we have to get everyone to switch [15:52:51.0956] We definitely can't change 5.9's behavior in a patch release, we don't plan on a 5.10, and 6.0 will have a min-target of ES2015. I wish we'd done it sooner already, but at this point if you need to use this library in ES5 the answer might be Babel for emit. [15:53:01.0533] * We definitely can't change 5.9's behavior in a patch release, we don't plan on a 5.10, and 6.0 will have a min-target of ES2015. I wish we'd done it sooner, but at this point if you need to use this library in ES5 the answer might be Babel for emit. [15:55:37.0935] it's going to be a language feature, not a library... 2025-12-05 [16:00:59.0970] Exactly, this is the main blocker for the proposal. I couldn’t get agreement to cache unfrozen template strings arrays, and TS is the biggest hurdle because it’s always unfrozen. [16:05:51.0455] So you're saying that this proposal cannot proceed with its strategy because there will be too many people depending on TS5.9 because they target ES5, but who want to use a polyfill or target a modern runtime? [16:06:15.0623] * So you're saying that this proposal cannot proceed with its strategy because there will be too many people depending on TS5.9 because they target ES5, but who want to use a polyfill or target a modern runtime with `String.dedent`? [16:12:18.0903] Strictly speaking it _can_ proceed, it's just that such people will get subtly wrong behavior if they try to use `String.dedent` [16:15:23.0276] I would advise us to ignore the spec divergence from TypeScript 5.9 and older in this case. By the time `String.dedent` is stage 4, it's likely that TS6 will be the latest stable version. [16:17:50.0879] Ideally, we’d be able to cache any arrays, and it wouldn’t be an issue. But if the committe decides we can only cache frozen arrays, people stuck on 5.9 will get much worse performance for common tagged templates and probably not realize it. [00:53:58.0896] can someone nudge Ruben to document his summaries/conclusions? I'll be working on this in a few hours. 2025-12-07 [14:27:32.0682] turns out this one was `.constructor` not `__proto__` per https://x.com/rauchg/status/1997362942929440937 2025-12-08 [22:19:13.0553] yeah I've been wondering about ways to defang Function.prototype.constructor for a while [22:19:32.0672] would be neat if references in js engines could be poisoned somehow [22:23:54.0587] maybe being able to see whether a call to Function is "direct", like with eval, could be beneficial [07:17:39.0662] Trusted types could be some part of the answer but obviously as opt-in as CSPs or the all-or-nothing flag in nodejs to disallow string eval. [07:22:46.0972] maybe not a common use case, but if code is only using the Function constructor to feature check syntax - that only requires the constructor - and doesn't need to call the actual function AFAIK [07:23:29.0899] as a slightly less restrictive form of dissalow-eval that still prevents these exploits [07:33:34.0800] https://github.com/tc39/proposal-symbol-proto did discuss defanging Function.prototype.constructor as well [07:34:22.0706] though I don't think its ideas are actually workable as written [07:35:48.0994] I do kind of enjoy the idea of saying that you can only access `Function.prototype.constructor` by literal `fn.constructor` syntax, not `fn['constructor']`, even though that would be a crazy violation of the language invariants [07:46:14.0598] we can just say that it's kinda like `{ __proto__: null }` and `{["__proto__"]: null }` being different and runway [10:26:06.0917] > <@devsnek:matrix.org> yeah I've been wondering about ways to defang Function.prototype.constructor for a while Does any legit code actually rely on `Function.prototype.constructor` being functional, or even matching `Function`? Why can't we just change it with something that doesn't evaluate? Possibly opt-in [10:27:37.0915] > <@aclaymore:matrix.org> we can just say that it's kinda like `{ __proto__: null }` and `{["__proto__"]: null }` being different and runway I think there's a difference between declaration and property access. On the access side, only `eval` behaves strangely. [10:28:05.0643] * I think there's a difference between declaration and reference access. On the access side, only eval behaves strangely. [10:31:55.0987] make it a function that's the same as the Function constructor but param lists must be simple and the body is prefixed with `return`? [10:55:38.0626] In HardenedJS, we replace Function.prototype.constructor with an exception thrower. Users of HardenedJS do sometimes run into libraries that are not ecosystem compatible, but I don’t recall any cases where this was a relevant hindrance. It doesn’t break `instanceof`. Nobody seems to legitimately depend on `(() => {}).constructor(code)` to do what is much more easily accomplished with `Function(code)`. [11:16:35.0772] lots of stuff depends on it matching; being functional is much rarer https://github.com/search?q=%28lang%3Ajs+OR+lang%3Ats%29+%22.constructor+%3D%3D%3D+Function%22&type=code [11:19:39.0079] has there been a proposal for like a `parses(src: string): boolean` method people could use instead of checking if calling `Function` throws? [11:19:39.0662] so that people could use it in no-eval contexts [11:19:53.0989] I guess ideally a `parses(src: string, asModule: boolean)` [13:54:59.0070] what I was suggesting was relaxing no-eval to throw when the code is actually evaluated - rather than when the function is constructed. assuming the goal was to support existing code. [14:15:18.0529] Richard Gibson: re https://github.com/tc39/ecma262/pull/3087 Chrome used to have a flag for setting timezone but apparently no longer does https://issues.chromium.org/issues/341232991 (also I don't know if actually allowed sub-minute offsets; it might have just been named timezones) 2025-12-09 [21:28:48.0938] > <@bakkot:matrix.org> lots of stuff depends on it matching; being functional is much rarer https://github.com/search?q=%28lang%3Ajs+OR+lang%3Ats%29+%22.constructor+%3D%3D%3D+Function%22&type=code Why are people doing this instead of `instanceof`!? [21:31:30.0040] `instanceof` is syntax you'd have to learn whereas property access and `===` you learn on your first day [21:32:07.0212] (also I expect `instanceof` is slower though I doubt anyone doing this would actually know that) [21:32:11.0094] Right but it's also the wrong check. It'd exclude AsyncFunction for example [21:32:33.0333] sometimes you want that! but yes [21:32:43.0018] I imagine a fair bit of this code predates AsyncFunction also 2025-12-11 [10:01:58.0176] Where can I report a typo on a tc39 page under the https://ecma-international.org/ domain? Not sure if any of us have the ability to edit that site or do we have to ask someone in ecma? [10:06:14.0979] "Ask ecma" = [@akirose:matrix.org](https://matrix.to/#/@akirose:matrix.org) [10:07:03.0393] Aki: 👋 hello! On https://ecma-international.org/publications-and-standards/standards/ecma-426/ it says "Support souce-level debugging" and I would very much like it if it said "Support source-level debugging" instead! [10:07:43.0197] What about sauce-level debugging instead? 2025-12-12 [04:13:49.0355] So needy. jk, I'm on it. [08:51:16.0820] Oh sorry for the delay - I just want to note that some teams prefer to keep checks consistent stylistically, even if it's not the best in isolation. For example, in that search result, one could argue that [reflux/refluxjs's `defineReact.js`](https://github.com/reflux/refluxjs/blob/24a476defcf3f1dc79a3f1f29bb7b46e0a51d327/src/defineReact.js#L460) is more readable because all six checks can use the same syntax. (n.b. I personally wouldn't make that argument and agree with preferring `instanceof`, and have never seen demand for any kind of static analysis to enforce this - this is just something that gets uttered once in a while)