A use case exists for a "library" (actually an extension application, defined with 'load-libraries') to have resources provided from a directory outside of webroot/rsrc. Is extending file system distribution for celerity feasible?
This is theoretically supported, but not documented, and may have some rough edges (I believe only one user has done an implementation).
- Extend CelerityResources (probably CelerityResourcesOnDisk) in your library. CelerityPhabricatorResources is an example.
- Implement required methods.
- Run bin/celerity map to rebuild all maps (CLI output should show that your resources were analyzed and your map was rebuilt).
- Your resources should work properly.
One outstanding issue I'm aware of is T5780 (you can't @require resources from the main map), but I think other things generally work. You can manage dependencies manually without too much effort if your external library is smallish.
We will eventually support this stuff in a more first-class, documented way, but building an external application ecosystem is a long-term goal and not a priority at present. You can read more in T5447. Basically, you're mostly on your own if you walk down this route for probably the next 1-2 years.
I got this to work as you suggested.
However, Javelin initBehavior is hard coded to 'phabricator' in the source_name variable in CelerityStaticResourceResponse. The source name identifies the location of the library map, so it could not be loaded. If Javelin.php could be changed so it passes $source_name and if $source_name is not set make it default to 'phabricator' there rather than in CelerityStaticResourceResponse, this would fix this.