tc39
Let's have exhaustive feature lists!
Opening this per https://github.com/tc39/test262/pull/3353#issuecomment-1247158634.
I think that in order to work towards userland packages being able to run test262 themselves, we need to do a better job ensuring that feature lists are exhaustive, and that unnecessary features aren't used (arrow functions when normal ones suffice, for example), without putting a burden on contributors.
I don't think a precommit script is a good idea specifically - either we need a way for maintainers to easily clean things up later, or, we need a CI check/formatter that helps contributors do the right thing without having to type it all out.
Personally I'd like to see this be treated as opt-in; I'm thinking along the lines of contributors should not have to pay attention to features that have been stage 4 for a while, so we shouldn't do this in CI, nor necessarily use a script to always automatically transform all arrow functions into normal functions, for example. But we should provide scripts to make it easy for userland packages to adjust whatever features they need on whatever subset of tests they need to do it on, and generally accept such PRs from userland packages without complaint.
In other words, a best-effort supported use case where that we facilitate where possible while not requiring additional effort from constituents higher on our list.
I'm totally fine with avoiding burden!
I'm not sure how practical it is tho for consumers to run scripts to mutate test262 on disk in order to run it.
I agree, I'm saying we should be willing to commit changes like this without necessarily making it a priority to make them preemptively.
I agree it doesn’t need to block merging, especially if we have a manual tool to detect and/or autofix them later.
Past discussions which are probably relevant here: #3196, #2862, #472 (links to this meeting note), #569. I think there are more, for example in review comments when the reviewer encouraged to use const instead of var or other other way around, i.e. to use var instead of const to target older engines.
Related to this, it also occurred to me that for features that long ago reached Stage 4, we could organize the features list according to what platforms are likely to want to run the tests. For example, we could remove all the individual typed array feature flags (Uint8Array, Int8Array, ...), and just use TypedArray as a catch-all feature flag, if there aren't any platforms where we want to run the tests that only implement a subset of the typed arrays.
Simplifying the feature flags sounds great - but personally I'd want to eventually run the tests on a ton of older browser/engine versions, so for typed arrays i'd want to confirm that there aren't any engines that implemented the pre-bigint TAs piecemeal.