🐛 plugins aren't resolved from the location of the config file

[adamhl8]

Environment information

CLI:
  Version:                      2.0.6
  Color support:                true

Platform:
  CPU Architecture:             aarch64
  OS:                           macos

Environment:
  BIOME_LOG_PATH:               unset
  BIOME_LOG_PREFIX_NAME:        unset
  BIOME_CONFIG_PATH:            unset
  BIOME_THREADS:                unset
  NO_COLOR:                     unset
  TERM:                         xterm-256color
  JS_RUNTIME_VERSION:           v22.6.0
  JS_RUNTIME_NAME:              node
  NODE_PACKAGE_MANAGER:         bun/1.2.17

Biome Configuration:
  Status:                       Loaded successfully
  Path:                         biome.jsonc
  Formatter enabled:            true
  Linter enabled:               true
  Assist enabled:               true
  VCS enabled:                  true

Workspace:
  Open Documents:               0

What happened?

Say you have a setup like this:

./configs/biome.json

{
  "root": false,
  "plugins": ["./pattern.grit"],
}

./biome.json

{
  "extends": ["./configs/biome.json"]
}

Run biome check:

  ✖ Error(s) during loading of plugins:
    Cannot read file.

Changing the plugin path to be relative to the root config makes it work:

./configs/biome.json

{
  "root": false,
  "plugins": ["./configs/pattern.grit"],
}

Plugins should be resolved relative to the specifying config.

Code of Conduct

• I agree to follow Biome's Code of Conduct

[ematipico]

That's how all paths work, not just the one that belongs to the plugin.

Not sure if we should categorise this as a bug, but if we changed this, we would need to change the resolution of paths as well e.g. files.includes

[github-actions[bot]]

Hello @adamhl8, please provide a minimal reproduction. You can use one of the following options:

• Provide a link to our playground, if it's applicable.
• Provide a link to GitHub repository. To easily create a reproduction, you can use our interactive CLI via npm create @biomejs/biome-reproduction

Issues marked with S-Needs repro will be closed if they have no activity within 3 days.

[arendjr]

I think we could choose to have an exception for plugins, which to me make some sense given that it’s a different use case and configs that are being extended wouldn’t reasonably know the location of plugins relative to the config they are being extended from.

That said, I’m not entirely sure yet we should make this change. And definitely agreed it’s not a bug, so l’ll convert this to a discussion for now.

[arendjr]

Note we had two other bug reports coming in from people who expected plugin paths to work relative to nested configurations. I'm starting to get convinced an exception as suggested here would be the right way to go :)

[Shadowlauch]

I ran into the same issue today. If I understand this issue correctly it makes it impossible to reference plugins in the root file of a monorepo setup. Other things I tried, that did not work:

• Referencing the pnpm package instead of the path
• Using glob patterns

[Jacse]

It's also impossible to reference plugins inside non-root files of a monorepo, at least for any configuration I tried.

[Jacse]

Hey @arendjr @ematipico sorry to tag, but was wondering if there's any update/decision on how to handle this?

[arendjr]

I believe this discussion is linked to this issue: #6376

Don't know if or when I'll get to it, but I'll close this discussion in the mean time.

[RJWadley]

consider the following structure

packages/a/biome.json        # extends configs/all.json
packages/b/server/biome.json # extends configs/server.json
configs/server.json          # extends all.json
configs/all.json             # includes myCustomPlugin
configs/plugins/myCustomPlugin.grit
biome.json                   # I don't even know what would go here, but the docs say I need it

I don't think this structure is possible with the way paths are resolved. If it works in the way the docs claim it does, any paths in 'plugins' or 'includes' must resolve properly from relative to several different configs, which is logically impossible.

I think this is confusing for "extends" and "plugins", but am not sure about "includes".
#7596

[bradleysmagacz]

+1 for this. we have a monorepo that extends configs from all over the place and I would like to be able to apply plugins to the base config