Vendor pruning should support D8-style root-projects
Overview
In 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.
Example use-case
There are two basic scenarios for deploying civicrm-core.git
:
- (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
Current behavior
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
Proposed behavior
- 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 thevendor/
tree, and re-runningcomposer 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.
Comments
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.
- https://github.com/barryvdh/composer-cleanup-plugin
- https://github.com/dg/composer-cleaner
- https://github.com/lichunqiang/composer-ignore-plugin
- https://github.com/liborm85/composer-vendor-cleaner
- https://github.com/drupal/core-vendor-hardening
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).