Support shareable custom usage data
See original GitHub issueI 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:
- 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 thebrowserslist-stats.json
file in this package, not to thebrowserslist-stats.json
file in whatever project extends this shareable config. - 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'
]
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (10 by maintainers)
Top GitHub Comments
Released in 4.8.
Yeap.
Let’s force one name. I do not see any problem with this convention.