Since Dart FFI landed this month, contributors adding or changing FFI need to have the dart command installed in order to generate clean diffs. The command is only used for formatting.

This is not good because it adds a non-Cargo dependency to a primary ICU4X contributor workflow. (Let's not debate whether or not adding FFI is a primary ICU4X workflow: the fact is that it absolutely is.)

We have a number of approaches:

0. Keep the current behavior. Contributors need to figure out how to install Dart on their own.
   • Pro: ?
   • Con: Most challenging for contributors
1. Add cargo make dart-install and make cargo make diplomat-gen fail if dart is not available
   • Pro: Better paved path for contributors
   • Con: Unclear how to make cargo make diplomat-install work on all platforms like Windows, etc.
   • Con: Still requires a non-Cargo dependency
2. Send an HTTP request to a public service like dartpad.dev for the Dart formatting if dart is not available (printing a notice that such behavior is taking place so that people can install dart to avoid the network call)
   • Pro: Primary contributor workflow just works out of the box
   • Con: Potential that the public service could break or block us at any time
3. Like 2 but host our own service and use it internally in icu4x tooling
   • Pro: Fewer external variables than using someone else's public service
   • Con: Potential hiccups hosting and maintaining our own service
4. Don't format the dart code
   • Pro: Most similar to how the other diplomat backends work. As long as the output is "good enough" it should be fine.
   • Pro: Easiest of all these options for all parties involved.
   • Con: Code doesn't look as pretty in the repo and needs to be re-formatted when vendored into a Dart project?
5. Don't check in the generated dart code
   • Pro: Easy
   • Con: Inconsistent with the other diplomat backends
6. Remove all generated diplomat code from the repo
   • Pro: Solves this and future similar problems
   • Con: Harder to reference the header files and run reproducible unit tests

Discuss with:

• @robertbastian
• @Manishearth
• @sffc