Barback should allow secondary inputs to be overwritten

[nex3]

Right now, if a transformer reads a secondary input and emits an output with the same name, that's considered an error, since the output conflicts with the pass-through version of that asset. This should instead be allowed as long as the output asset is read by the transformer as a secondary input (it's already allowed for primary input, since those are consumed and rendered unavailable).

[lrhn]

Removed Area-Library label.
Added Area-Pkg label.

[anders-sandholm]

Removed Library-Barback label.
Added Pkg-Barback label.

[munificent]

Merging this with 16612. I think the way this will work is that if a transformer explicitly consumes a secondary input, then it won't be an error to output an asset with that ID.

If it doesn't exclude that input, I think by default that should be an error to make sure the user knows the transformer is stepping on something.

---

Added Duplicate label.
Marked as being merged into #16612.

[nex3]

I don't think this should be marked as a duplicate. We don't know without diving in whether the fix for issue #16612 will fix this automatically or not -- it's very possible this will require some additional support.

If it doesn't exclude that input, I think by default that should be an error to make sure the user knows the transformer is stepping on something.

I disagree. I think if a user has requested something as a primary or secondary import, they should be allowed to overwrite it without explicitly consuming it. Otherwise I think we're imposing a bunch of unnecessary busywork on common transformer cases.

---

Added Triaged label.
Marked as being merged into #.

[nex3]

After some thought, we've decided not to support this. It broke several important guarantees that Barback would otherwise offer. From my email to Bob:

Right now Barback has two very nice properties which are mutually incompatible
with either consuming or overwriting secondary inputs. The first nice property
is that when a user requests an asset, they don't need to wait for the entire
world to build; they just need to wait for that asset. The second is that if a
user makes a change and requests an asset affected by that change, that
request will block until the requested asset is available.

Now, suppose we allow secondary inputs to be overwritten. You have some
intermediate phase with inputs A and B, and a transformer T for which A is
primary. Now suppose A changes, and we start to re-run T. We're faced with a
choice: do we mark B as dirty?

If we don't mark B as dirty, any requests to B (or anything generated using B)
will continue to succeed while T is chugging along. If T then decides to use B
as a secondary input and overwrite it, those requests will have served stale
data -- this violates the property #­2 above and forces the user to constantly
refresh the page to get the latest version of their app.

On the other hand, if we do mark B as dirty, then if T doesn't overwrite B it
will have been marked dirty and then available again despite no changes. This
will cause every transform using B to re-run itself. On a large scale, it will
mean that any change to any file will effectively require a re-compilation of
the entire package in which that file resides.

Both of these are serious usability issues for user that reach beyond just
transformers that want to overwrite secondary inputs. We should take a close
look at the use-cases for this sort of overwriting and see if we can come up
with a way of addressing them that has less troublesome consequences.

We discussed use-cases and alternatives and decided that there aren't any critical use-cases that require this functionality. The most concrete use-case we have is of a spriting transformer that wants to remove all the PNGs that it used to construct a sprite, but issue #4 should address that case sufficiently.

---

Added WontFix label.

[nex3]

Issue #17843 has been merged into this issue.

[DartBot]

This issue has been moved to dart-archive/barback#17.