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?
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
This is theoretically supported, but not documented, and may have some rough edges (I believe only one user has done an implementation).
Roughly, you:
- 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.
Comment Actions
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.
Thanks.