dart-lang
Figure out a resolution for conflicting sources and generated outputs in non-root package
It's possible to see a source files that has the same AssetId as a file we want to generate. Today with deleteFilesByDefault we ignore this, and without deleteFilesByDefault we report it in a non-obvious way, then if the user selects 'y' (as most would) we end up ignoring it.
https://github.com/dart-lang/build/pull/696 Turns this into a warning rather than a silent ignore, but we're potentially hiding sources that the user may want to see in their deploy directory.
We need to figure out a better strategy.
- Should we allow this at all?
- Do we need to offer some way to configure yourself out of the situation? Relying on upstream package owners to fix these conflicts is likely a non-starter (@kevmoo to comment)
- Can we do a better job even in the root directory at detecting the scenario where the output is built to cache vs not?
Should we allow this at all?
I don't think we should - this should eventually be an error once a basic e2e example with angular/test can work without these issues.
Do we need to offer some way to configure yourself out of the situation? Relying on upstream package owners to fix these conflicts is likely a non-starter (@kevmoo to comment)
I don't think this is a non-starter, it should be a rare case. We need to choose a more namespaced name for the ddc module files and all other code generators should do the same.
Can we do a better job even in the root directory at detecting the scenario where the output is built to cache vs not?
Not sure what you mean exactly by this one - do you mean the situation where a code generator changes its setting to start outputting to cache?
Can we do a better job even in the root directory at detecting the scenario where the output is built to cache vs not?
Not sure what you mean exactly by this one - do you mean the situation where a code generator changes its setting to start outputting to cache?
That is one possibility, or where someone writes a file.template.dart for some reason. If we have a source file conflict against something which we expect to overwrite (because of write_to: source) it's most likely because of a deleted .dart_tool or similar. If we have a source file conflict against something which we expect to write to the build cache it's less likely because it's a fresh AssetGraph, and more likely that there is something the user wants to pay close attention to. At the least we should change the wording of our warning.