The signal for browser support for a package is ternary; a yes/no/unknown toggle for the Firefox, Chrome, and Safari icons.
I think more nuanced compatibility options are necessary. JavaScript API support in web browsers is a mixed bag. For example, my package uses the URLPattern API implemented by Deno and Chromium browsers. I have no option to show that Chrome & Edge etc support this but Firefox and Safari do not natively yet.
Additionally, being able to link to a package README section on compatibility and support would be helpful. With the URLPattern example, this can be polyfilled to work in Firefox/Safari. I'd preferred not to bundle that into my package. The same polyfill works in Node/Bun too I believe, so an option for written compatibility notes would benefit all runtimes.
MDN's baseline compatibility could be useful data to present. What if I can mark my package as using an API like URLPattern and compatibility tables are automated? Then if other browsers add support it can update itself.
These are just ideas, but I think the requirement for more browser compatibility options is a strong one.
I think this is where the 'Dependencies' overview falls short, highlighting only what other packages a package depends on. It really should include a more fine grained overview of dependencies:
Global variables (which would catch all web APIs and runtime namespaces such as Deno, or Bun)
Individual module imports per package, as some packages are actually module libraries (think lodash for example), and information about which individual modules from those libraries is as important in these cases. (I think this deserves it's own issue: #310)
The signal for browser support for a package is ternary; a yes/no/unknown toggle for the Firefox, Chrome, and Safari icons.
I think more nuanced compatibility options are necessary. JavaScript API support in web browsers is a mixed bag. For example, my package uses the URLPattern API implemented by Deno and Chromium browsers. I have no option to show that Chrome & Edge etc support this but Firefox and Safari do not natively yet.
Additionally, being able to link to a package README section on compatibility and support would be helpful. With the
URLPattern
example, this can be polyfilled to work in Firefox/Safari. I'd preferred not to bundle that into my package. The same polyfill works in Node/Bun too I believe, so an option for written compatibility notes would benefit all runtimes.MDN's baseline compatibility could be useful data to present. What if I can mark my package as using an API like
URLPattern
and compatibility tables are automated? Then if other browsers add support it can update itself.These are just ideas, but I think the requirement for more browser compatibility options is a strong one.