biome-ignore for multiple lines

[yphoenix]

There are places where we just need to turn biome off for a routine or section of lines. Turning it off for a single line is great (ESLint has this), but it would be great to turn it off / on for a bunch of lines, eg:

// biome-rule-off
// biome-rule-on

Or some variation of the above

[k-utsumi]

NOTE: Prettier only support Markdown

• Support prettier-ignore-start/end for other languages (not only Markdown) prettier/prettier#5287
  • My hack comment

---

ESLint supports that.

/* eslint-disable */

alert('foo');

/* eslint-enable */

—— REF (Configure Rules - ESLint)

We want to use it too 🙏

[ematipico]

I don't think we will support this kind of suppression system

[sassomedia]

@Conaclos I appreciate you looking into this but the code above is merely an example. There can be various use-cases (aside from naming) where rules need to be disabled for multiple lines or blocks of code. A single line is insufficient and file-based disabling is too much if it should only affect a limited scope.

Since multi-line ignore is supported in both ESLint and Prettier, it is difficult to transition code bases to Biome without that. This is quite an essential feature. Please consider adding it. 🙏

[k-utsumi]

Does Prettier support multi-line ignore? 👀
I guess Prettier just supports Markdown. (REF)

[ematipico]

eslint does (obviously).
jshint does
stylelint does, in the same kind of way that eslint does

I was referring more to modern linters, like Ruff and Clippy. Biome is modern, so we have a chance to avoid mistakes from past tools (I am not saying that the proposed feature is a mistake).

Since multi-line ignore is supported in both ESLint and Prettier

That's not precisely correct, and I explain you way. Like Biome, the suppression comments in Prettier and ESLint have different semantics.

In the Biome formatter (and Prettier) a suppression comment works on "expressions", that's because these blocks of expression can fold on multiple lines depending on different heuristics. Because of that, the suppression system works on the semantics of the nodes of the CST/AST, and doesn't rely on a text ranges (line/columns).
In the Biome analyzer (and ESLint), a suppression comment works on "ranges", where a range has a start (line/column) and an end (line/column). The semantic of the suppression comment is closer to a classic AST/CST, because diagnostics usually have a start and end that can be easily identified inside the CST/AST.

Implementing a feature as-is, like it is proposed, could create more confusion for the users (looking at other replies, I can see there's already confusion). Let me know if there's a way forward, and I hope you understand the difficulties we could face.

[sassomedia]

I'm not sure what you are suggesting. ESLint changes generally do not interfere with Prettier changes and vice versa. There are rare exceptions where they do and in those cases, disabling them for small parts of code always fixes the issues. So despite their different handling of code and being physically separate codebases, they can work alongside each other.

Setting the underlying structure aside, the issue of disabling multiple lines or blocks of code from linting/formatting still remains the same. There is no confusion about that.

Essentially, how the issue is solved for internally does not matter to the enduser of the linter. If a user were to consider Biome over ESLint & Prettier to port their codebase to, they would expect the same or better features, not less. If not all rules are supported, fine, this can be manually addressed in code review if needed. But what cannot stand is leaving hundreds or thousands of ignore comments all over the codebase. This is a mess that the tool should solve for.

I do like Biome for its speed and ease of use but the fact that it cannot do the fundamental task of excluding small parts of code from its operation makes it impossible to port certain codebases. There is just no getting around that.

[yphoenix]

Even if turning the rule off and on was block scoped it would be something if arbitrary lines can’t be supported - and I can see why it would be hard, but block scoped rules seems like it would be possible.

[k-utsumi]

I want to use it in cases like this.

example

const theme = {
	colors: {
		// biome-ignore format:
		primary:   '#000',
		secondary: '#000',

		success: '#000',
		info: '#000',
		warning: '#000',
		error: '#000',


		tokens: {
			// ...
		},
	},
}

If it's not acceptable,
I'll probably write a hack code.

example

const theme = {
	colors: {
		// biome-ignore format:
		...{
			primary:   '#000',
			secondary: '#000',

			success: '#000',
			info:    '#000',
			warning: '#000',
			error:   '#000',
		},

		tokens: {
			// ...
		},
	},
}

[emptyflask]

IMO this is a necessary feature.

Also, as the previous commenter suggested, table alignment (or just whitespace preservation) can be a huge win for readability.

// simple example
export const getCoords = (elem: Element) => {
  const box = elem.getBoundingClientRect()
  return {
    top:    box.top    + window.scrollY,
    right:  box.right  + window.scrollX,
    bottom: box.bottom + window.scrollY,
    left:   box.left   + window.scrollX,
  }
}
// vs
export const getCoords = (elem: Element) => {
  const box = elem.getBoundingClientRect()
  return {
    top: box.top + window.scrollY,
    right: box.right + window.scrollX,
    bottom: box.bottom + window.scrollY,
    left: box.left + window.scrollX,
  }
}

[ematipico]

Isn't this possible already? https://biomejs.dev/formatter/#ignoring-code

[emptyflask]

Isn't this possible already? biomejs.dev/formatter/#ignoring-code

Indeed it is. I didn't think to add the comment above the entire object/array, thanks for pointing that out.

[universalmind303]

+1 for this feature.

When working with external apis/sdks, they don't always conform to camelCase conventions.

AWS SDK's use PascalCase for example

   const command = new CreateTableCommand({
      // biome-ignore lint/style/useNamingConvention: we dont control aws' api
      TableName: name,
      // biome-ignore lint/style/useNamingConvention: we dont control aws' api
      AttributeDefinitions: [
        {
          // biome-ignore lint/style/useNamingConvention: we dont control aws' api
          AttributeName: "base_uri",
          // biome-ignore lint/style/useNamingConvention: we dont control aws' api
          AttributeType: "S",
        },
        {
          // biome-ignore lint/style/useNamingConvention: we dont control aws' api
          AttributeName: "version",
          // biome-ignore lint/style/useNamingConvention: we dont control aws' api
          AttributeType: "N",
        },
      ],
      // biome-ignore lint/style/useNamingConvention: we dont control aws' api
      KeySchema: [
        // biome-ignore lint/style/useNamingConvention: we dont control aws' api
        { AttributeName: "base_uri", KeyType: "HASH" },
        // biome-ignore lint/style/useNamingConvention: we dont control aws' api
        { AttributeName: "version", KeyType: "RANGE" },
      ],
      // biome-ignore lint/style/useNamingConvention: we dont control aws' api
      ProvisionedThroughput: {
        // biome-ignore lint/style/useNamingConvention: we dont control aws' api
        ReadCapacityUnits: 1,
        // biome-ignore lint/style/useNamingConvention: we dont control aws' api
        WriteCapacityUnits: 1,
      },
    });

I don't want to supress the rule for the entire file, but only for a specific code block.

[ematipico]

Can't this be addressable with the new option you have for this rule?

[universalmind303]

It can but it feels quite unintuitive as I have to manually override each individual file

biome.json

  "overrides": [
    {
      "include": [
        "fileA.ts", 
        "fileB.ts", 
        ".."
      ],
      "linter": {
        "rules": {
          "style": {
            "useNamingConvention": {
              "options": {
                "conventions": [{
                  "selector": {
                    "kind": "objectLiteralProperty"
                  },
                  "formats": ["camelCase", "PascalCase"]
                }],
                "strictCase": true
              }
            
            }
          }
        }
      }
    },

but then its overridden for the entire file

fileA.ts

// yay this part works now
const command = new CreateTableCommand({
  TableName: name,
  // ...
});

// but now this is also allowed.

const obj = {
  Hello: 'world'
}

Scoping it to a specific block allows the developers to better state their intentions.

// biome-disable lint/style/useNamingConvention: we dont control aws' api
const command = new CreateTableCommand({
  TableName: name,
  // ...
});
// biome-enable

const obj = {
  Hello: 'world' // Now errors out as expected
}

Tucking it away in the config file makes it much less clear as to WHY it's disabled

[Safvan-tsy]

+1

[staciax]

+1

[Conaclos]

I still think we should change how Biome ignore comments work. Instead of applying the ignore comment to a single node, we could apply the suppression comment to the entire tree of node that is commented. This could solve a long-standing issue where our formatter add parentheses around an expression with an ignore comment and move the ignore comment before the parentheses. Although this change could lead to a perf regression?

This solution has also a caveat: it no longer allow ignoring a single node. For example ignoring useNamingConvention on a function ignores the rule for all bindings inside the function. I think it is a fair caveat to keep things simple.

[ematipico]

Although this change could lead to a perf regression?

I am not worried about the perf changes, but the breaking change of the logic

[philtompkins4]

+1 this feature would be really handy when working with helm charts with keys that don't conform the naming convention

[park-jemin]

+1 - running into areas where files are littered and made unreadable with biome-ignore comments, and it feels incredibly unergonomic to have to modify the config file just to make exceptions for a single file, which could quickly blow up into a 1000+ line config in a medium-large project that's been standing for a few years.

While I understand biome aims to be modern in its approach, I feel that this feature really hampers adoption for existing codebases. I love biome in all other aspects, but would appreciate if the team could reconsider

[ematipico]

I'm evaluating this feature, but it still lacks a proper proposal that is inline with our suppression grammar, and the one proposed by OP doesn't fit.

I'm not very fond of this tactic for many reasons, so I'm not very invested in it, but maybe other maintainers feel differently and want to implement it. However, I know we have the infrastructure to support it.

If people are interested, we could open a bouty and see how it goes. People can volunteer to claim the bounty too. I'm also willing to implement it if we reach the bounty target

[tats-u]

I think "ignore In next block" like the following is safer than on/off toggle.

export async function getFoo(client: PrismaClient): Promise<SomeType> {
  const rawResult = await client.$execRawTyped(sqlStatement());
  // biome-ignore-in lint/style/noNonNullAssertion: Prisma don't respect NOT NULL in rows in TypedSQL
  return {
    foo: rawResult.foo!, // row with NOT NULL
    barBaz: rawResult:bar_baz!, // row with NOT NULL
    qux: rawResult.qux!, // row with NOT NULL
  };
  // note: end of biome-ignore-in because it's the end of { ... } here
}

[ematipico]

I think that can work, however I think I will for biome-ignore-start and biome-ignore-end

[tats-u]

-start/end may easier to be implemented.
C# uses #pragma warning disable/restore like this way.

[ematipico]

Closing in favour of #4569