Remove stage 1 tests, make stage 2 tests non-significant

[chicoxyzzy]

sequel of #1631

[zloirock]

Let's also remove stage 2 and stage 3 tests - it's just proposals and they shouldn't be taken into account, after - ES5 - now 2020, it's supported almost everywhere and makes no sense to store those results, and finally ES2015+ 👍

[ljharb]

Stage 3 proposals ship in browsers, and are both significant and should never be removed.

Nobody should ever be shipping pre-stage-3 proposals (and folks doing so have already harmed the web irreparably in the past), so this sounds like a good plan to me.

[zloirock]

Seems you forgot that compat-table is not only the place where could be found browsers implementation status, it's also the place where you could see the list of proposals, unlike tc39/proposals with simple examples of usage in the feature detection tests, with implementation status in transpilers and polyfills. Some stage 1, stage 0 and even pre-strawman proposals have a spec text, so missing spec text is not an argument. Some proposals are just adding to the standard legacy non-standard features like it was with features like trimLeft. Also, compat-table is a database about the features support and some tools use it even for proposals - sure, not by default. Also, those tests moved to the upper stages / to the standard on the proposal advancement by changing only one word instead of writing the full test case.

[chicoxyzzy]

Stage 1 means that it worth it for TC39 to discuss a problem space and nothing more. Any code samples and spec text are in flux and shouldn't be considered as something stable. We should remove stage 1 proposals for the same reason Babel has removed stage presets. There is no matter if any tools support stage 0 or stage 1 proposals cause on these stages they are not more valuable than any other user library solving the same problem. Having those in compat table only adds a misconception that syntax and semantics are set in stone and that some tools or polyfills are better than others because of their stage 0 / 1 support.

[zloirock]

Even stage 3 proposals semantics are not set in stone, even features from the stable ES sometimes changes. However, it's not the reason that they should not be here. If something is a stage 1 proposal it does not mean that for this proposal should not be a transform or a polyfill. The keyword here is PROPOSAL, the ESNext table for proposals, not for something stable.

[chicoxyzzy]

Stage 3 features usually doesn't have major high-level API changes. Stage 2 are considered as something that committee expects to land to JS engines eventually, but they can significantly change over time indeed. That's way they marked as non-significant in this PR. Everything below stage 2 is not expected to land to the spec and engines yet. This is also the reason why stage 1 and stage 2 proposals are not listed on the main page in the proposals repo

[zloirock]

Stage 3 features usually doesn't have major high-level API changes.

.item at the previous week? (and seems without any serious work before because of the possible conflict with another proposal - it could be resolved before if TC39 saw another, early-stage proposal which was removed from the table) Too many stage 3 features were seriously changed.

I perfectly know how it works, so I can't understand why you explain it here -) One more time - the ESNext table for proposals, for something unstable, so it will be strange to expect that it's something that will not be changed. In the table, you could see the stage level - the level of stability.

[chicoxyzzy]

.item at the previous week?

That's why I wrote "usually".

the ESNext table for proposals

it is a part of compatibility table and proposals below stage 2 couldn't be counted as something that will ever land to engines while stage 2 means that committee explicitly stated that it expects them to land eventually.

[ljharb]

The name of a method is not a high-level change, it is quite a trivial change. It is exceedingly rare for anything else to change in stage 3, and the web compatibility of a name is an expected possible change in stage 3.

[ljharb]

The existence of early proposals in this table contributes to user confusion about the reality that it is dangerous and foolhardy to rely on pre-stage 3 proposals in their code. If the individual proposal repos lack sufficient examples, then their readme is the place to make improvements.

[zloirock]

Ignorance is strength? -) No, thanks. Could be better, in this case, to add a note that the usage of early-stage proposals is dangerous.

[ljharb]

Sometimes, yes, that is true - not all information is equally valuable, and spreading misinformation is harmful.

Stage 0 and stage 1 proposals do not have any solution at all yet - so it's simply incorrect to have feature tests for them. It was a mistake to include them in the first place (my mistake, if i recall), and they should be removed now.

[zloirock]

Awesome 👍 I'm waiting for the next step -)

[afmenez]

@chicoxyzzy, The title says "make stage 2 tests non-significant", but it doesn't seem to be the case after the merge...

[chicoxyzzy]

@afmenez you mean that non-significant tests are counted in overall score? Yes, that's true, this issue exists for a long time. I'm not sure if we have an issue for that problem or not.