I don't think people would consciously write projects: []; however, it is very possible to end up with passing an empty array in cases of:

module.exports = {
  projects: [
    // TODO: bla bla
    // "tsconfig1.json",
    // TODO: bla bla
    // "tsconfig2.json",
  ],
};

module.exports = {
  projects: getProjects().map(...),
};

And in both cases preventing the empty array seems unnecessarily uncharitable.

I think I remember why I use [] now, it doesn't allow false at all,

I don't like {project: undefined}, because {} is the same(and I'm the author of unicorn/no-useless-undefined rule), but {} can't prevent the parser change default value, I also don't like {project: null}(again.. author of unicorn/no-null rule).. {project: []} is my best choice to exist this function.

And getProjectConfigFiles returns different result for {project: null} and {project: []}...

The issue with using [] is that the ESLint merges arrays and objects. null will override or by overridden, but empty objects and empty arrays will be merged and not override.

That's why our disable-type-checked config explicitly uses null.

It looks like this might be slightly different in flat configs though - arrays override but objects merge.

We should treat an empty array the same as off, regardless.

So, are we still doing this? To me it sounds like putting an extra patch on something that was very logical in the first place.

Yeah I no longer have motivation to push for anything here. The differences make sense and I'm happy with the status quo. Thanks all 😄