Description
Have you read the Contributing Guidelines on issues?
- I have read the Contributing Guidelines on issues.
Motivation
I'm recently thinking about what qualifies as a breaking change (also mentioned in #6113). But not exactly API breaking changes, but environment support.
For example, we unintentionally dropped support for Node versions below 14.13, which didn't support statically analyzing some named export patterns in ESM, causing our import {program} from 'commander'; in create-docusaurus to fail. The solution to that was simple: we specified the version requirement to a minor (#7271).
The support for ESM is constant-improving, and it's almost impossible to confidently say "we support Node v14+" unless we make sure that every code path works in Node v14.0. This will be a huge problem for #6520 in the long term. In addition, there are some libraries like [email protected] that specifically require Node v14.15+ — what do we do in this case for people on a minor below 14.15?
In general I don't think it's very hard to issue an error and ask people to bump their Node to a higher minor version, but it will be a breaking change nevertheless, if we agree that "any change that prevents a site from building is a breaking change". However, how do we actually know? Do we always run Node tests on the lowest permitted version?
My proposal is to support the latest minor version of maintenance LTS and active LTS (which often contain backported features from the current version), and all versions of the "current" release. We probably won't use a lot of shiny new features, but it will unblock us from doing certain meaningful things.
On the other hand, there's also the issue of browser support. JavaScript APIs suffer less in this aspect because most of them remain polyfillable/transpilable, although we did fall into a few pitfalls in the past (e.g. #3680). CSS is a more prominent issue. We recently used a few new CSS features in Infima (e.g. facebookincubator/infima#246) for good will, but browser support doesn't even cross 90%. CSS is not polyfillable. Should we do this?
An easy answer is we support the default browser query (>0.5%, not dead, not op_mini all), but do note that this includes IE 11 as well (although it soon won't). Would it be reasonable to say "the last three major versions of Chrome and Firefox, and the last three minor versions of Safari"? This will impact every site visitor of a particular site, not just the site creators themselves. This is also the reason why we are conservative at using APIs like scroll-behavior.
Self-service
- I'd be willing to do some initial work on this proposal myself.