Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: add more Browser Compatibility package settings #164

Open
dbushell opened this issue Mar 4, 2024 · 1 comment
Open

Comments

@dbushell
Copy link

dbushell commented Mar 4, 2024

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.

@jollytoad
Copy link
Contributor

jollytoad commented Mar 20, 2024

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: Suggestion: Finer grained module dependencies #310)

@lucacasonato lucacasonato moved this from Needs Triage to Needs Plan in JSR Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Needs Plan
Development

No branches or pull requests

2 participants