Custom Mappings for file extensions to .json linter/formatter

[hanseltime]

Hey all!

I just made the switch from eslint and am overall pretty thrilled with the outcome. As I was setting up my config though, I discovered that I don't have a way (at least that I have been able to find), of applying the same json rules to some of my config files.

I use SWC for compilation and as such, I have .cjs.swcrc and .esm.swcrc files that are json. Since these aren't part of the "well-known names", it doesn't look like I can get them to be linted or formatted via the normal json rules. And since the pattern that I am following is to create variable-prefixed files that don't end in .json, I wouldn't want them to be in the extension/well-known name mapping for the json tool.

Ideally, I would like to be able to set something like:

{
   "extensionMapping": {
       "*.swcrc": "json",
  }
}

Has this been brought up before and would this be a valid idea within the project's mandate? I wouldn't be opposed to contributing a fix if that's the case.

[ematipico]

That's a good suggestion. I would move the option under files.

I'm a bit hesitant about the use of Regex, though.

[hanseltime]

Ah gotcha. So the syntax would be more like:

{
  "files": {
      "extensionMapping": {
          ".cjs.swcrc": "json"
      } 
  }
}

Or actually, would it be better to have the extension mapping object have known keys (i.e. the same keys as the formatters and linters) and then people can just add their own files there:

{
   "files": {
      "extensionMapping": {
           "json": [
              ".cjs.swcrc",
              ".esm.swcrc",
           ]
      }
   }
}

I think as a MVP, it would be fine to not have regex/glob.

On the regex front though, I guess I have 2 thoughts:

1. In a lot of my repo workflows, it's common that I will probably create a new environment prefix if my environments as some deploy/integration test needs arise. Since Biome will quietly go about its business when I add those new files, having to hard-code every file means that I will probably let some slip through the cracks if I have multiple contributors - a regex on a pattern feels helpful for catching this.
2. I'm assuming that some of the concern is about the performance overhead of running regexes against every file biome finds. I haven't looked deeply at the code base yet, but am mainly curious if that's the biggest concern. If regexes did get implemented, I think it would need to be part of a last-resort system (i.e. is it a known extension, if not, then try the regexes and encode that information on the file object for reuse).

If there is an agreed upon scope and you guys are open to it, I may try my hand at the codebase (since I'm assuming this is a pretty low priority for the larger project).

[Conaclos]

We could simply map extensions to languages. For example .swcrc could map to json.
I wonder of this could be part of <language>.parser ?

{
  "json": {
      "parser": {
          "extensions": [".swcrc"]
      } 
  }
}

However, I am not sure if this will play well with our current infra.
We could indeed just put the mapping under files:

{
  "files": {
    "languages": {
      "json": [".swrc"]
    }
  }
}

or a new global parser?

{
  "parser": {
    "extensions": {
      ".swrc": "json"
    }
  }
}

[ematipico]

If we map a file to JSON (for example), I would expect to be:

• parsed
• analyzed
• formatted

So it wouldn't make sense to have a parsing option

[dyc3]

I agree with @ematipico, I think it makes the most sense for it to go under files. This section of the config has other options that deal with indicating what/how files are processed (see: include, ignore)