Output on lint tasks

[TxHawks]

In all the examples in the examples directory, the lint task is defined with an empty outputs array like so, despite the fact that the package.json tasks have the --fix flag on for ESLint.

In my understanding, the --fix flag means that files could be changed by the task and therefore should be recorded in the outputs array. Am I wrong or is this an omission in the examples?

[mehulkar]

So a couple things:

1. It seems weird to me that lint scripts have the --fix flag on them. I'd expect the examples to have lint:fix for that, for example.
2. Even though files are changed by lint, I don't think it makes much sense to capture any outputs, because presumably, eslint is changing files, not creating files. The benefit of outputs is that any files created by a task can be cached (so that a second run can use the cache). If you ran turbo run lint && turbo run lint, I'm not sure any cached output from the first run would really help.

This is an interesting question though! I'd be curious what @vercel/turbo-oss thinks as well

[TxHawks]

I was under the impression that output is tied, well, to output. Why would it matter if its creating files or changing them? The content on disk should be changed just the same anyway. Am I missing something obvious?

[nathanhammond]

A few things:

• eslint --fix is intended to be non-material changes only. In other words your code should still function identically.
• outputs are intended to capture and restore generated assets that were constructed as part of that task, which can then be available for future tasks (either downstream builds, or releases, or ...) or other developers working on the same repository. Lint changes are generally not relevant to that.
• Turborepo is creating the cache hash based upon the state of the directory prior to running lint. So even with the lint changes this is still safe.

It's a bit confusing that it is doing this, but it is not wrong for running lint prior to build, and it's useful for turbo run lint.

[TxHawks]

While it's fair to say that in the context of a build build task the output of eslint --fix is immaterial, I don't think this would necessarily be the case when in the general context of such a task, which is what I think we should be thinking of when defining tasks in a pipeline.

I'd say that eslint --fix is meant to ensure consistency and "correctness" throughout the code base, and could be run as part of a pre-commit or pre-push hook, where the output will then be committed.

In that sense, I feel that the examples might be misleading. It's indeed not wrong for running lint prior to build, but it could be confusing or just plain wrong regarding general use of a lint task