README.md
Same filename in this branch
- 11.x composer/Plugin/ProjectMessage/README.md
- 11.x composer/Plugin/Scaffold/README.md
- 11.x composer/Plugin/RecipeUnpack/README.md
- 11.x core/themes/olivero/README.md
- 11.x core/themes/claro/images/core/README.md
- 11.x core/themes/starterkit_theme/README.md
- 11.x core/modules/package_manager/tests/fixtures/fake_site/README.md
- 11.x core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/project-with-illegal-dir-scaffold/assets/README.md
- 11.x core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/sites/default/README.md
- 11.x core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/README.md
- 11.x core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/README.md
- 11.x core/tests/PHPStan/README.md
- 11.x core/tests/README.md
- 11.x README.md
Same filename and directory in other branches
- 7.x misc/brumann/polyfill-unserialize/README.md
- 7.x misc/typo3/phar-stream-wrapper/README.md
- 9 composer/Plugin/ProjectMessage/README.md
- 9 composer/Plugin/Scaffold/README.md
- 9 core/themes/olivero/README.md
- 9 core/themes/claro/images/core/README.md
- 9 core/themes/starterkit_theme/README.md
- 9 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/project-with-illegal-dir-scaffold/assets/README.md
- 9 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/sites/default/README.md
- 9 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/README.md
- 9 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/README.md
- 9 core/tests/README.md
- 9 core/assets/vendor/modernizr/README.md
- 9 README.md
- 10 composer/Plugin/ProjectMessage/README.md
- 10 composer/Plugin/Scaffold/README.md
- 10 core/themes/olivero/README.md
- 10 core/themes/claro/images/core/README.md
- 10 core/themes/starterkit_theme/README.md
- 10 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/project-with-illegal-dir-scaffold/assets/README.md
- 10 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/sites/default/README.md
- 10 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/README.md
- 10 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/README.md
- 10 core/tests/README.md
- 10 core/assets/vendor/modernizr/README.md
- 10 README.md
Why do we need the updated_module
fixtures?
Because there is a need to thoroughly test the updating of a module. See \Drupal\Tests\package_manager\Build\PackageUpdateTest
.
This requires 2 versions (1.0.0
and 1.1.0
) of the same module (updated_module
), each with a different code bases.
The test updates from one version to the next, and verifies the updated module's code base is actually used after the update: it verifies the updated logic of version of \Drupal\updated_module\PostApplySubscriber
is being executed.
\Drupal\fixture_manipulator\FixtureManipulator
cannot manipulate code nor does it modify the file system: it only creates a "skeleton" extension. (See \Drupal\fixture_manipulator\FixtureManipulator::addProjectAtPath()
.)
Why do we need the alpha
fixtures?
To be able to test that php-tuf/composer-stager
indeed only updates the package for which an update was requested (even though more updates are available), no fixture manipulation is allowed to occur. This requires updating a path
composer package repository to first serve contain one version of a package, and then another. That is what these fixtures are used for.
File
-
core/
modules/ package_manager/ tests/ fixtures/ build_test_projects/ README.md
View source
# Why do we need the `updated_module` fixtures? Because there is a need to thoroughly test the updating of a module. See `\Drupal\Tests\package_manager\Build\PackageUpdateTest`. This requires 2 versions (`1.0.0` and `1.1.0`) of the same module (`updated_module`), each with a different code bases. The test updates from one version to the next, and verifies the updated module's code base is actually used after the update: it verifies the updated logic of version of `\Drupal\updated_module\PostApplySubscriber` is being executed. `\Drupal\fixture_manipulator\FixtureManipulator` cannot manipulate code nor does it modify the file system: it only creates a "skeleton" extension. (See `\Drupal\fixture_manipulator\FixtureManipulator::addProjectAtPath()`.) # Why do we need the `alpha` fixtures? To be able to test that `php-tuf/composer-stager` indeed only updates the package for which an update was requested (even though more updates are available), no fixture manipulation is allowed to occur. This requires updating a `path` composer package repository to first serve contain one version of a package, and then another. That is what these fixtures are used for.
Buggy or inaccurate documentation? Please file an issue. Need support? Need help programming? Connect with the Drupal community.