Allow the use of URLs inside the extends option to ease adoption inside large companies and organizations.

[arthurfiorette]

Inside large organizations and companies, maintaining a biomejs configuration file for each repository shortly becomes inconsistent and hard to maintain. If we could do the following for all repositories would be an awesome way to sync format and linting rules across the entire org.

{
  "$schema": "https://biomejs.dev/schemas/1.3.3/schema.json",
  "extends": ["https://raw.githubusercontent.com/MYORG/MYREPO/TAG/biome.json"],
}

This is similar to what is being proposed by #644, but much more easy to implement.

Similar to relative paths, the only different behavior is to fetch the config url if it starts with http:// or https:// from the internet instead of the file system. Authentication inside the url should also be handled, like http://token:[email protected]/my-file.json.

When the downloaded content cannot be parsed into json, an error should be thrown and block the biome to continue working. If it cannot be downloaded because there no internet access, probably we should just ignore this extends entry and emit a warning.

[ematipico]

This is an excellent alternative to #644, although it comes with some drawbacks that should be highlighted:

• it requires an HTTP request, which is way slower than a file system request
• the CLI will become much slower depending on the connection of the user
• the implementation requires some level of caching. If a user wants to use multiple commands in CI, we would download the same file multiple times. The same thing applied to the LSP

[GabenGar]

• Even worse, a random dev-only runtime doing an HTTP request on formatting is quite a side effect to have, especially in large organizations. Probably won't even pass the security department anyway.
• Should be an opt-in CLI flag then, the person who would need this functionality is going to be completely content with being bottlenecked by the network.
• Should be a separate command to collect HTTP modules, this will allow to list external dependencies with various metadata and provide various HTTP specific arguments, such as allowed origins, a proxy and certificates for HTTPS. And do that in a semi-atomic fashion. But at that point it is a reinvention of package management.

So yeah, introducing HTTP logic to a codebase without it is a major pain. It looks like a job of a project-specific install/update scripts, at least there are expectations of them going to the internet to do their arbitrary things.

[arthurfiorette]

But don't you think this may be a better feature than having to publish a package containing the shared config, require it everywhere, keep it updated and implement module resolving steps (which will be a bug factory forever since we have a trillion different package managers, like pnpm and its weird but fast resolution) into biomejs? There's no security problems to public share a biomejs json config and basic http configuration/authentication can be baked at the url or a url object like "extends": [{ url: "text.com/biome.json", proxy: ... }, "text2.com/biome.json"] which can be simply direct passed to the http crate biome is using.

[GabenGar]

But don't you think this may be a better feature than having to publish a package containing the shared config, require it everywhere, keep it updated and implement module resolving steps (which will be a bug factory forever since we have a trillion different package managers, like pnpm and its weird but fast resolution) into biomejs?

Offloading dependency management will not make the entire pipeline less of a bug factory.

There's no security problems to public share a biomejs json config and basic http configuration/authentication can be baked at the url or a url object like "extends": [{ url: "text.com/biome.json", proxy: ... }, "text2.com/biome.json"] which can be simply direct passed to the http crate biome is using

Any non-ancient org will implement auth as headers, so the potential implementation has to accommodate for that (and probably respect cookie directives too). And also does not interact with outside networks through unencrypted protocols. By a complete coincidence you omitted the protocols from URLs in your example, which makes their meaning ambiguous.

[arthurfiorette]

Offloading dependency management will not make the entire pipeline less of a bug factory.

Dependency resolution in js is hard, but if it can be easily done outside of the JS land, fair.

By a complete coincidence you omitted the protocols from URLs in your example, which makes their meaning ambiguous.

I typed it on my phone 😁