Browserslist: Support shareable custom usage data

[galvarez421]

I would like to create a shareable Browserslist config package that can be reused/shared across multiple projects. I am able to do this just fine except if I want to use custom usage data ('my stats') that is relative to the shareable config rather than relative to projects whose Browserslist configs extend the shareable config.

Here is what I am trying to achieve:

1. Shareable Browserslist config package contains index.js (the config-exporting module), a browserslist-stats.json file, and a package.json file (for installation via npm/Yarn). The config in the package should include a query to use custom usage data resolving to the browserslist-stats.json file in this package, not to the browserslist-stats.json file in whatever project extends this shareable config.
2. Install shareable Browserslist config package and include 'extends browserslist-config-mypackage' in browserslist query passed to other tools (postcss-preset-env and babel-preset-env in my case).

When I do this, I get the error message BrowserslistError: Custom usage statistics was not provided (unless I include a browserslist-stats.json file in my project, but that does not satisfy what I am trying to achieve).

It is probably good to preserve the current meaning of 'my stats' and how it is resolved for backwards compatibility but also so that a shareable config can still indicate that the target config should use its own custom usage data.

Here is one idea. Maybe 'my' could be replaced in any query with the name of a package containing a browserslist-stats.json file? For example:

browserslist-config-mypackage/index.js:

module.exports = [
  '> 0.5% in my stats', // custom usage data resolves to browserslist-stats.json corresponding to whichever config extends this config. In the case of chained extends, custom usage data resolves relative to the config at the end of the chain. This is the current behavior right?
  '> 1% in browserslist-config-mypackage stats' // custom usage data resolves to browserslist-stats.json in this package
];

Browserslist query in project:

[
  'extends browserslist-config-mypackage',
  '> 0.5% in browserslist-config-mypackage stats', // This would NOT be redundant
  '> 1% in browserslist-config-mypackage stats', // This WOULD be redundant
  '> 5% in browserslist-config-google stats', // Presumably there would be no limit to how many sources of custom usage data you could use in queries
  '> 5% in browserslist-config-wordpress stats'
]

[ai]

I am not sure that it is a good idea to post stats to npm package since npm package developer will always forget to update the stats.

What do you think about:

1. You add browserslist-ga to your sharable config dependency.
2. You add postinstall script to your config npm package
3. This script look for stats file. If it didn’t find stats file, it calls browserslist-ga to create it.

[galvarez421]

@ai thank you for the prompt reply.

I am not sure that it is a good idea to post stats to npm package since npm package developer will always forget to update the stats.

I plan to version and update the stats just like I would with any other resource that I share across multiple projects, e.g., shared Browserslist config, shared ESLint config, etc. Is that strategy not congruent with the intent of the custom usage data feature? I should note that my goal is to have reproducible builds, so I wouldn't want the stats to update and potentially change the compiled code based on those stats unless I were to explicitly change the stats (rather than, for example, having the build process use the latest stats available each time).

Regarding your suggestion:

• I don't want to use browserslist-ga in this case, although I would use something like browserslist-ga-export, per https://github.com/browserslist/browserslist-ga/issues/6. Regardless, I don't think this difference would affect the rest of the setup you suggest.
• Would this setup address the scenario of a developer forgetting to update the stats? As I noted above, I don't think forgetting to update the stats would be an issue in my case (at least not any more of an issue than forgetting to update any other dependency would be an issue), but I think you see it as an issue so I'm wondering if you think the proposed setup solves that issue.
• I think this setup could achieve my primary goal ("create a shareable Browserslist config package that can be reused/shared across multiple projects"), so thank you for the suggestion! However, I do still think there would be value in extending Browserslist to support something like what I described for reasons including the following:
  
  
  
  • Would make it clear that stats from a shared package are being used as expected. In the setup that you propose, if the stats are installed into a project via the postinstall script, couldn't I thereafter change the custom usage data and then not really be able to know if the shared stats are being used, as initially installed, by referring to the package.json file and Browserslist config?
  
  
  • Would allow users to specify at least 2 different sources of custom usage data.
  
  
  • Would allow users to use shareable custom usage data without having to have or override a local custom usage data file.
  
  

[ai]

What do you think about this temporarl solution:

BROWSERSLIST_STATS=./node_modules/any-module/stats.json npx gulp css

So with BROWSERSLIST_STATS env variable you can set any path for statistics

[galvarez421]

That sounds like a good workaround for now. Thanks, I'll give it a try!

[ai]

I found other user with same problem https://github.com/postcss/autoprefixer/issues/1053

Seems like we need some solution

[AndrewLeedham]

@ai any thoughts on a potential solution here? I can potentially put a PR in if I know the direction. I tried setting process.env.BROWSERSLIST_STATS inside the shareable config itself, but I am guessing that is ran in a spawn or exec process so it does not propagate to browserslist itself.

I would have thought looking for browserslist-stats.json in the location of the extended package would be the most ideal solution?

[ai]

I like the idea of > 5% in browserslist-config-google stats to load browserslist-config-google/browserslist-stats.json and > browserslist-config-stats/us stats to load browserslist-config-stats/us/browserslist-stats.json.

You will need to add a new query to QUERIES list and use the same safety technique from extend query (prohibbit . and .. in config name).

[AndrewLeedham]

That could work, presumably you would be able to use the > 5% in browserslist-config-google stats within browserslist-config-google itself? Also what about custom stats file names, would this just enforce browserslist-stats.json?

[ai]

That could work, presumably you would be able to use the > 5% in browserslist-config-google stats within browserslist-config-google itself?

Yeap.

Also what about custom stats file names, would this just enforce browserslist-stats.json?

Let's force one name. I do not see any problem with this convention.

[ai]

Released in 4.8.