Vendor pruning should support D8-style root-projects
civicrm-core:composer.json, there are a series of script declarations. One of the most common elements of these scripts is that the clean out example files.
There are two basic scenarios for deploying
- (A) CiviCRM as root-project/application
git clone https://github.com/civicrm/civicrm-core.git civircm cd civicrm composer install
- (B) CiviCRM as library/dependency in another root-project/application
composer create-project drupal/recommended-project my-site cd my-site composer require civicrm/civicrm-core
In scenario (A), various files (examples/docs/tests) under
vendor are cleaned out.
In scenario (B), they are not.
For a list of specific items that are currently cleaned, see:
grep safe_delete tools/scripts/composer/*.sh
- It should be possible to clean out these artifacts in both scenarios.
- The cleaning mechanism and rules should be the same (shared) in both scenarios.
- The cleaning should be optional - so that (a) it is possible to create a development-oriented build and (b) it is possible to choose some cleaner that is designated by the CMS community.
- (Low priority) The cleaning should be enabled by default (i.e. opt-out).
- When cleaning scenario (B), one should converge on identical code in each sub-case: (i) creating a project and adding CiviCRM to it anew; (ii) taking an existing
composer.json(with CiviCRM and everything else), deleting the
vendor/tree, and re-running
composer install; (iii) performing updates on an existing project.
Many of th rules in
tools/scripts/composer/*.sh could potentially be replaced by some kind of composer-based cleaning plugin.
The list of composer plugins includes a few focused on cleaning up
vendor. I haven't fully assessed how these match up with the proposed behavior.
If you were comparing (A) w/d7 against (B) w/D8, you might observe that cleaning artifacts is less important in the latter case because
vendor is hidden. That means
*.php files aren't web-accessible. Never-the-less, even in (B), there is a file-sync operation to publish assets, and this could publish example/test/doc files in JS/CSS/etc format. Vulnerabilities in that case are less likely and more constrained (e.g. it probably cannot execute arbitrary PHP code; but OTOH the browser trusts JS files based on their origin, and that might be exploitable in some poorly written JS demo file).