feat: Allow additional rules and TypeScript-specific rules to be directly passed to generateEslintConfig rather than requiring users to concatenate or manually munge them into place

[jswalden]

No description provided.

[jswalden]

This fixes #47. I am not terribly wise in the ways of all this, so if you have opinions on doing any of this better in some way, they are probably right. 😅

[Julusian]

I am wondering how necessary this is to do.

Because its entirely possible to add new rules, using your own path definitions as new items in the array of rules (eg https://github.com/bitfocus/companion-module-zoom-osc-iso/blob/main/eslint.config.mjs)

And I don't think this would conflict with the existing rules in any way, most of the blocks we put in by default are turning off certain rules for certain paths because they add a lot of unnecessary noise (in my repositories)

[jswalden]

Unless I'm misreading the docs, in that example, those added rules will apply to files where those rules were disabled by the generated config info -- because "config objects that don’t specify files or ignores apply to all files that have been matched by any other configuration object". So the added new rules could in fact conflict with ones specified in the generated rule config objects.

The only reason that example doesn't have issues is that it doesn't specify any rules that do conflict. (Whereas in my example, I do specify a rule definition, for n/no-unpublished-import, that alters a rule you've turned off. My very tentative sense is that that rule is valid and it would be good to not turn it off -- but that pure dev dependencies like @companion-module/tools and in my case @jest/globals in tests are the exception.)

I do not know enough about defining configs to make my case here with particular confidence, sadly.

[Julusian]

yeah Im hitting the issue that it feels like this shouldn't be necessary, but I need some real examples to prove the cost/benefit either way.

What I am afraid will happen if we aren't careful is that this generator function will end up with many options, that make it easier to build a config from scratch.

What you have in your file currently doesn't feel like it is fighting anything currently, and looks quite tidy/simple to me (only one block and only one path being ignored/matched. and it doesn't look like its going to break with future changes to the generated config) so I am leaning towards saying lets leave it as is for now, but I am happy to reopen this discussion if someone feels strongly, or starts to get a complex config that could benefit from more being done.
How does that sound to you?