Built-in support for yearly baseline

[jkrems]

One thing that has been suggested in the past is to provide builds for certain feature sets by year. E.g. closure compiler's --browser-featureset-year or the srcset attribute suggested by @mathiasbynens. Maybe something like featuresetXXXX could be added as a built-in? The definition would be tricky admittedly since it requires ongoing work at the beginning of each year.

[jkrems]

Example usage may look like this:

{
  "exports": {
    ".": [
      {
        "featureset2019": {
          "browser": "./dist/browser-modern.js",
          "main": "./dist/node-modern.js"
        }
      },
      {
        "browser": "./dist/browser-es5.js",
        "main": "./dist/node-es5.js"
      }
      "./dist/es5-mega-bundle.js"
    ]
  }
}

[mathiasbynens]

The definition would be tricky admittedly since it requires ongoing work at the beginning of each year.

For Closure Compiler, we've decided to keep the definition as simple as possible. On January 1st of each year, we note down the latest stable versions of the following browsers:

• Chrome
• Edge
• Firefox
• Safari
• iOS Safari
• (each bundler could make up their own list of special-cased browsers, although alignment would be ideal)

Features that are supported in all those browsers become part of the feature set of that year.

cc @concavelenz

[jkrems]

To clarify, the tricky part is "who has the definite list of what featureset 2020 contains" because each bundler / compiler / runtime doing their own data gathering on Jan 1st each year seems error prone. Not unsurmountable but adds an unknown. So basically your parenthetical "alignment would be ideal". I still think it's super valuable to have and assuming it's independent of "browser", it could be used for node as well, even though it would require node to define its own [language] feature set in terms of browser features.

[guybedford]

This is exactly the sort of reason to try and build a central location for this information and the meanings of these definitions to try to get alignment between tools.

It is yet to be seen if it will be possible though, or if this proposal is the right approach, but it seems like it can only be beneficial to try.

To try to better work out how to go about getting alignment on these definitions, I've started a thread in #7 around the process there.

The proposed target definitions discussed here entirely seem to fit the requirements though to me!