2024-07-03 [08:08:20.0111] anyone joining maintainers meeting today? [08:15:49.0404] I can if anyone else is 😅 [14:59:32.0448] (i couldn't make it today) [15:22:09.0376] we didn't have much to discuss. just triaged PRs 2024-07-07 [16:49:18.0530] could I ask for https://github.com/tc39/test262/pull/3994 to get merged? proposal has been at stage 3 for a while [16:49:42.0091] I have some followups but I'll send them as their own PRs so they can be reviewed independently 2024-07-08 [21:56:24.0415] it needs a rebase but the conflict shouldn't be tricky; i can take care of it tomorrow if nobody objects by then 2024-07-12 [10:38:12.0197] Are Test262 people able to help with this? https://github.com/boa-dev/boa/issues/3431#issuecomment-2226049270 [10:41:38.0027] can we get in touch with Brian? I haven't had any response on PRs to those repos, but I haven't yet tried contacting Brian directly [10:42:20.0998] I've put it on our meeting agenda for next time [10:43:16.0806] Thank you CC canadahonk [10:43:48.0256] * Thank you
CC canadahonk& linusg [11:19:12.0047] > <@pchimento:igalia.com> can we get in touch with Brian? I haven't had any response on PRs to those repos, but I haven't yet tried contacting Brian directly I can reach out to Brian in the meantime [11:37:59.0886] I’ve chatted with him, he said he’s not involved anymore and it’s up to the committee/test262 editors to decide what they want to do about it. [11:39:10.0795] * I’ve chatted with him, he said he’s not involved anymore and it’s up to the committee/test262 editors to decide what they want to do about it. He’s happy to give keys if someone wants to upstream the fork or if it needs to be archived etc. [11:40:30.0013] * I’ve chatted with him, he said he’s not involved anymore and it’s up to the committee/test262 editors to decide what they want to do about it. He’s happy to give keys if someone wants to upstream the fork or archive if that’s what test262 project decides. [14:50:58.0846] JaseW: is he willing to transfer it into the tc39 github org, and npm owner add one of us, so we can keep maintaining it? [14:53:01.0077] ljharb: yes he would be fine with that [14:53:29.0320] beautiful, let's do that, and then we're empowered to archive it too if that's what we decide [14:53:46.0239] he should be able to bounce it into tc39-transfer still, and he can npm owner add me 2024-07-18 [20:59:06.0018] heads up on https://github.com/tc39/test262/pull/4123 - i'd love them to be merged before the agenda deadline in 2 days :-) [02:19:25.0042] ljharb: do you consider them ready? I don't know if I'll have time to get them reviewed in detail, but I can take a quick look [08:24:22.0316] yes [08:25:31.0521] In general, there's a lot of test262 stuff out for review, going back to last year. What's the strategy for getting through it and landing everything? [09:39:49.0168] we've been splitting it up and landing it in chunks 2024-07-22 [08:41:12.0472] Hello! Sorry for bothering, I just had a question for the test26 maintainers. Have you ever considered adding more metadata to the `features.txt` file? For context, at Boa we're maintaining a map of all the current test262 features and its corresponding spec edition that each feature was introduced on (https://github.com/boa-dev/boa/blob/main/tests/tester/src/edition.rs). However, I think it could be worth having this on the repo itself, since I think it's pretty common for people to filter tests per edition. [08:41:35.0461] * Hello! Sorry for bothering, I just had a question for the test262 maintainers. Have you ever considered adding more metadata to the `features.txt` file? For context, at Boa we're maintaining a map of all the current test262 features and its corresponding spec edition that each feature was introduced on (https://github.com/boa-dev/boa/blob/main/tests/tester/src/edition.rs). However, I think it could be worth having this on the repo itself, since I think it's pretty common for people to filter tests per edition. [08:41:45.0763] i believe very few implementations actually implement to match editions [08:42:27.0375] and given that it's a living standard, anything merged to github is part of the language - the edition is more of a snapshot for historical/ecma reasons [08:42:37.0110] that said it'd be fine to include that data i guess? [08:42:48.0818] it's also in the proposals table, but not programmatically mappable to test262 features [08:42:53.0688] I'm curious why boa organizes its JS feature support by editions like that. Most engines treat features individually, uncorrelated. [08:45:41.0067] > <@ljharb:matrix.org> i believe very few implementations actually implement to match editions It's not used in the engine itself, we also try to match the latest standard. However, most people checking out the engine ask things like "what is your conformance per ES version?" and we just figured that we could use the features to collect that data [08:45:52.0492] Instead of having to filter the tests manually per version [08:47:04.0201] hm, that's fair, that's somewhat how https://compat-table.github.io/compat-table/ and https://node.green are organized [08:47:31.0110] how do they answer that question for other engines? [08:50:13.0734] As you've probably figured out, they also maintain the same mapping [08:50:19.0401] E.g. test.fyi https://github.com/test262-fyi/test262.fyi/blob/81861b7aeeb518326147ab2826d4adc184f14686/site/generate.mjs#L242-L458 [08:50:32.0848] * E.g. [test262.fyi](https://github.com/test262-fyi/test262.fyi/blob/81861b7aeeb518326147ab2826d4adc184f14686/site/generate.mjs#L242-L458) [08:51:32.0030] It would definitely reduce a lot of duplicate effort if that mapping was directly on the main source, which is test262 [08:55:26.0388] ah, i'd assumed they just didn't answer that question. if they maintain the same mapping then i can't imagine why we wouldn't want to incorporate that into the main repo [09:00:18.0065] Nice! Shall I open an issue then? I can work on this, but we would need to discuss the exact form of the metadata (file format, edition repr, features that haven't been published yet, etc.) [09:14:50.0000] sgtm, thanks [09:43:28.0881] https://github.com/tc39/test262/issues/4161 2024-07-24 [08:05:23.0445] anyone joining the maintainers meeting today? [08:07:06.0721] * ~~IIRC, I received a cancellation that there was no agenda? Was that not the case?~~ [08:12:03.0395] I was going to! Then I had an insurance call come up. I'll be back some week soon 🙇🏻 [08:59:48.0186] can't this week, i'm traveling [10:16:58.0931] quick stamp on https://github.com/tc39/test262/pull/4167? fixing would be easier than reverting, but in order not to keep Anba waiting with a broken tree I'll accept his revert if no one can stamp this in the next little while [10:23:20.0449] commented a fix [10:23:43.0739] will stamp now so you can land it once that's in [10:24:14.0205] * ptomato: commented a fix [10:24:20.0704] many thanks! 2024-07-25 [06:30:16.0694] Hi! I'm working on the `import defer` tests, and I ended up building my own utility to be able to author multiple JS modules in the same file, so that I don't have to read across multiple files to see what a test is doing. For example, https://github.com/tc39/test262/blob/main/test/language/import/import-attributes/json-idempotency.js would be rewritten in a single file like this: ````md Copyright (C) 2021 the V8 project authors. All rights reserved. This code is governed by the BSD license found in the LICENSE file. ## main.js ```js /*--- esid: sec-parse-json-module description: The same object representation is returned to all import sites flags: [module, async] features: [import-attributes, json-modules, globalThis, dynamic-import] ---*/ import viaStaticImport1 from './json-idempotency_FIXTURE.json' with { type: 'json' }; import {default as viaStaticImport2} from './json-idempotency_FIXTURE.json' with { type: 'json' }; import './json-idempotency-indirect_FIXTURE.js'; assert.sameValue(viaStaticImport1, viaStaticImport2); assert.sameValue(globalThis.viaSecondModule, viaStaticImport1); import('./json-idempotency_FIXTURE.json', { with: { type: 'json' } }) .then(function(viaDynamicImport) { assert.sameValue(viaDynamicImport.default, viaStaticImport1); }) .then($DONE, $DONE); ``` ## json-idempotency_FIXTURE.json ```json {} ``` ## json-idempotency-indirect_FIXTURE.js ```js import value from './json-idempotency_FIXTURE.json' with { type: 'json' }; globalThis.viaSecondModule = value; ``` ```` Is this something that I could upstream in the test262 repo, similarly to how we have the scripts to generate tests based on .template/.case? [06:30:24.0431] * Hi! I'm working on the `import defer` tests, and I ended up building my own utility to be able to author multiple JS modules in the same file, so that I don't have to read across multiple files to see what a test is doing. For example, https://github.com/tc39/test262/blob/main/test/language/import/import-attributes/json-idempotency.js would be rewritten in a single file like this: ````markdown Copyright (C) 2021 the V8 project authors. All rights reserved. This code is governed by the BSD license found in the LICENSE file. ## main.js ```js /*--- esid: sec-parse-json-module description: The same object representation is returned to all import sites flags: [module, async] features: [import-attributes, json-modules, globalThis, dynamic-import] ---*/ import viaStaticImport1 from './json-idempotency_FIXTURE.json' with { type: 'json' }; import {default as viaStaticImport2} from './json-idempotency_FIXTURE.json' with { type: 'json' }; import './json-idempotency-indirect_FIXTURE.js'; assert.sameValue(viaStaticImport1, viaStaticImport2); assert.sameValue(globalThis.viaSecondModule, viaStaticImport1); import('./json-idempotency_FIXTURE.json', { with: { type: 'json' } }) .then(function(viaDynamicImport) { assert.sameValue(viaDynamicImport.default, viaStaticImport1); }) .then($DONE, $DONE); ``` ## json-idempotency_FIXTURE.json ```json {} ``` ## json-idempotency-indirect_FIXTURE.js ```js import value from './json-idempotency_FIXTURE.json' with { type: 'json' }; globalThis.viaSecondModule = value; ``` ```` Is this something that I could upstream in the test262 repo, similarly to how we have the scripts to generate tests based on .template/.case? [07:41:42.0763] * Hi! I'm working on the `import defer` tests, and I ended up building my own utility to be able to author multiple JS modules in the same file, so that I don't have to read across multiple files to see what a test is doing. For example, https://github.com/tc39/test262/blob/main/test/language/import/import-attributes/json-idempotency.js would be rewritten in a single file like this: ````markdown Copyright (C) 2021 the V8 project authors. All rights reserved. This code is governed by the BSD license found in the LICENSE file. ## main.js ```js /*--- esid: sec-parse-json-module description: The same object representation is returned to all import sites flags: [module, async] features: [import-attributes, json-modules, globalThis, dynamic-import] ---*/ import viaStaticImport1 from './json-idempotency_FIXTURE.json' with { type: 'json' }; import {default as viaStaticImport2} from './json-idempotency_FIXTURE.json' with { type: 'json' }; import './json-idempotency-indirect_FIXTURE.js'; assert.sameValue(viaStaticImport1, viaStaticImport2); assert.sameValue(globalThis.viaSecondModule, viaStaticImport1); import('./json-idempotency_FIXTURE.json', { with: { type: 'json' } }) .then(function(viaDynamicImport) { assert.sameValue(viaDynamicImport.default, viaStaticImport1); }) .then($DONE, $DONE); ``` ## json-idempotency_FIXTURE.json ```json {} ``` ## json-idempotency-indirect_FIXTURE.js ```js import value from './json-idempotency_FIXTURE.json' with { type: 'json' }; globalThis.viaSecondModule = value; ``` ```` Is this something that I could upstream in the test262 repo, similarly to how we have the scripts to generate tests based on .template/.case? **EDIT**: Lets discuss here: https://github.com/tc39/test262/pull/4170