Thinking about it, I can't imagine anyone calls the other tasks; I could just make all of them call the one lint task instead.

I have a vague recollection that maybe these were separated in order to have separate cache files? But it seems like separating scripts (very small) from compiler (very large) would have minimal utility on that front. I might be thinking of something else. @weswigham probably remembers.

🤷‍♀️ That's the best answer I have, too. Iirc, I think they had different rules enabled, too, since we didn't have most semantic lints enabled for scripts, but did for the compiler at some point.

They do have different rules enabled, but as far as I can tell, eslint fully understands nested configurations by looking up the file system tree; I tested things out by introducing lint errors in both places, and it behaved as expected. e.g., I triggered no-unnecessary-qualifier by adding a ts.Something into the compiler, and it complained, and that rule is only introduced in src/.eslintrc.

Ah, makes sense.

Any opinions on whether or not I just delete the old tasks? I'm not sure anyone is running them directly. Maybe it's useful to run on just the scripts or something, but I don't quite know if that matters given you can see lint errors in your editor pretty readily...

I only run gulp lint, personally.

I run gulp runtests-parallel and when the tests start passing I stage my changes, commit, push, and then see lint failures immediately after pushing or in CI, personally.

Cool. I'll just delete the other sub-tasks and if someone ends up wanting them, they are easy enough to restore.