The 'pip' or 'conda' distribution of airflow is not a full distribution for anyone wanting a turn-key package. The 'dist' folder is not included in '.../www_rbac/static'.
The expectation of the package manager is to have a useable asset once the package is installed. Packages relying on additional dependencies tend to stick with packaging route, so that they can expose those dependencies during build time (think C-backed packages, for instance).
'conda install airflow' did not expose this need for an additional step, and based on numerous other issues open in the Airflow backlog, chances are 'pip install' suffers the same fate.
Preferably for the proposed solution, just prescribe defaults for the 'dist' folder, and include ways to override it through some mechanism. Airflow already has this pattern for 'webserver_config.py', so the pattern is already there, if you'd want to extend the pattern to these assets. Whatever the solution, 'pip install' or 'conda install' should provide a usable, turn-key package without the need for an additional build system downstream.
Many of our deployment targets don't have npm, and won't ever have it. We are then forced into a position of composing an environment at a tag revision, then using 'conda-pack' to send that revision to another place where the static resources can be built, back to a second 'conda-pack' with the built bundle. From our perspective, this build pattern has minimal lift over the previous static deployment path and is mainly a hassle.