we purposely never added any files to any of our configs because there are usecases like vue that have .vue extensions -- so if we restrict the globs to certain extensions then we lock those users out.

additionally all of our rules work fine on JS files -- so restricting them to just TS files wasn't necessary. People always wrote "TS-first" lint configs and left .js as an exception.

The only files we have has actually always just been via eslint-recommended:

This also had the benefit of being an easy way to automatically make .ts files get enabled by default in ESLint.

Personally I'd say "probably not a good idea" to adding a files to base:

• if we add it alongside (i.e. convert the config to an array) then that's a breaking change as consumers would need to change their config files with the version bump.
• if we add it to the single object then that's a breaking change as it limits the config from working on exotic extensions.

we purposely never added any files to any of our configs because there are usecases like vue that have .vue extensions -- so if we restrict the globs to certain extensions then we lock those users out.

additionally all of our rules work fine on JS files -- so restricting them to just TS files wasn't necessary. People always wrote "TS-first" lint configs and left .js as an exception.

Fully aligned

The only files we have has actually always just been via eslint-recommended:
[...]
This also had the benefit of being an easy way to automatically make .ts files get enabled by default in ESLint.

This is the part that I find pretty unexpected as a user. I'd have thought that base would include a "global includes" for TS files, so to speak, so that I'd just need to specify rules after that point in order for them to apply to TS files. Relying on eslint-recommended seems... odd. If I'm an individual-rule-choosing-user, I guess I'd do this? 😢

export default tseslint.config(
   // enable TS lang support
   tseslint.configs.base,
   // enable linting of TS files
   { files: tseslint.configs['eslint-recommended'].files },
   {  
      rules: { /* etc */ },
   },
);

Personally I'd say "probably not a good idea" to adding a files to base:

• if we add it alongside (i.e. convert the config to an array) then that's a breaking change as consumers would need to change their config files with the version bump.

Blehhhh, behavior-wise, I was thinking it would be ok, but I totally forgot about the object -> array shape change being breaking 🙃. tseslint.config()/defineConfig() really proving their worth here over raw export default [tseslint.configs.base].

• if we add it to the single object then that's a breaking change as it limits the config from working on exotic extensions.

Aligned, yeah it would only make sense as a separate config object.

So, definitely agreed there isn't really anything we can do without a breaking change (short of creating a new config altogether, which is totally unwarranted). Maybe something to consider for v9?