Change Request: add support for Baseline years to require-baseline

[rviscomi]

Environment

Node version: v20.0.0
npm version: v9.6.4
Local ESLint version: v9.21.0 (Currently used)
Global ESLint version: Not found
Operating System: darwin 23.6.0

What problem do you want to solve?

In addition to Baseline newly and widely available, features can also be expressed in terms of the year they became newly available. For example, here is the list of features considered Baseline 2023. This can be useful for developers who prefer to set a fixed browser support target that they can periodically reevaluate, rather than a moving target like widely available. However, the require-baseline rule currently only supports two modes: newly or widely available.

What do you think is the correct solution?

I'd like the require-baseline rule to also support Baseline years. So a user can say that they target features released in or before a given year, eg available: 2021, and the rule will not allow any features newer than that.

Participation

• I am willing to submit a pull request for this change.

Additional comments

Related to #67, because Baseline years are fixed targets, they don't have the same transience issues as tests targeting newly available features.

[nzakas]

This is an interesting idea, although I'm wondering how useful this will be in the real world. Yes, it would be helpful for testing, but is there any reason someone would want to peg baseline to a previous year?

[nzakas]

It's also not clear to me what "Baseline 2023" means. Does that mean everything that became newly available in 2023? Widely available in 2023?

[Faithfinder]

At my current job I always want latest, but I can easily imagine a future where my primary client is some heavily restricted government agency that's running 5 year old software as a policy

[runofthemillgeek]

@nzakas that was a bit confusing to me also. When I expand the filter here to start from an earlier year, it shows both Newly & Widely so I guess it means either of the two: https://webstatus.dev/?q=baseline_date%3A2022-01-01..2025-01-01&sort=baseline_status_asc

IDK if released in a given year is helpful, I can see "before year XXXX" probably helping but the language/API could be clarified.

[rviscomi]

Yeah right now there's not a lot of guidance around how and why to target a specific Baseline year as opposed to newly or widely available. We'll be adding more docs and guidance to the WebDX CG and web.dev sites, meanwhile there are a couple of major use cases we're looking at:

• Wide availability is defined as 30 months after a feature becomes available across the major browsers, but this could either be unnecessarily long or prohibitively short (as in @Faithfinder's example) depending on a site's particular user base or support policies. Targeting features by year allows you to fine tune your support level according to your analytics, eg the years having 98%+ browser support as shown in this case study from RUMvision.
• Third party libraries or CMSs don't necessarily know their end users, and so they may prefer a more conservative compatibility target. Aligning to a specific year also helps developers understand what features were supported at the time of the release, since newly and widely available are moving targets that depend on your frame of reference.

It's also not clear to me what "Baseline 2023" means. Does that mean everything that became newly available in 2023? Widely available in 2023?

Baseline 2023 includes all features that became newly available in 2023. For the purposes of this feature request, setting a target availability of 2023 would mean that ESLint allows all features that became newly available in or before 2023. Or to put it another way, any feature that was not yet available in the core browsers by the end of 2023 would not be allowed.

[nzakas]

Okay, so Baseline 2023 means everything that was newly available by the end of 2023. 👍 Let's called this Newly Baseline 2023 just for a moment.

Is there also a use case for a Widely Baseline 2023, where it's everything that is widely available by the end of 2023? So maybe you could configure the rule like this:

{
    rules: {
        "require-baseline": ["error", { availability: "widely", year: 2023 }]
    }
}

[philipwalton]

This is an interesting idea, although I'm wondering how useful this will be in the real world. Yes, it would be helpful for testing, but is there any reason someone would want to peg baseline to a previous year?

@nzakas to give a bit more context on the use case for Baseline years: we (on the Chrome team) have heard from developers and site owners that they want to use Baseline to simplify their browser support policy, but they want to do so based on analytics data from their own user base.

So the concept of "Baseline Years" is our solution to this request, and we're actively talking to a number of analytics providers to see if they'd be willing to add some sort of "Baseline Year" report to their product to help customers determine what Baseline year makes the most sense for them. The RUMVision integration that @rviscomi mentioned above is one example of this.

Another example is a tool I'm building that allows Google Analytics users to export a browser usage report and then the tool will analyze that data and generate a Baseline report showing what percentage of their users' browsers fully support each of the various Baseline versions. Here's a very rough prototype of what that report might look like—and this is showing real browsing data from the site web.dev:

From a report like this, you could imagine a site owner looking at the data and determining that they're comfortable picking a Baseline year that is supported by at least 98% of their users. In the case of web.dev that would be "Baseline 2021", but of course that version might be different for another site. This data also shows (at least for web.dev) that going back further than Baseline 2020 will not make a big difference in terms of the number of additional users you'd be supporting.

So then once a site owner identifies which Baseline year to support, the next step in the workflow would be for them to configure their tools to take that Baseline year version as an input and help them do a few things:

1. Ensure they don't use features not supported by their target Baseline version (which we hope ESLint can play a big part in).
2. Identify APIs that they can actually use now, that they may have incorrectly assumed were not widely supported across their users' browsers.
3. Tailor the output code generated by their build tools to take maximum advantage of the features that are available in their Baseline version (e.g. not including unnecessary polyfill, fallback, or transpilings).

That last item above is a bit of a stretch goal, but I mentioned it to give you a sense for how we're imaging people might use Baseline to optimize their sites for the modern features available to their users.

Regarding "Baseline Widely available", we see that as something that makes sense as a general recommendation, and is definitely useful for site owners who don't have any data on what browsers their users have. But for site owners who do have access to that data, we want to make it as easy as possible for them to use Baseline in a way that is more specifically tailored to their needs (rather than a one size fits all solution).