README.md

Same filename in this branch
  1. 11.x composer/Plugin/ProjectMessage/README.md
  2. 11.x composer/Plugin/Scaffold/README.md
  3. 11.x composer/Plugin/RecipeUnpack/README.md
  4. 11.x core/themes/olivero/README.md
  5. 11.x core/themes/claro/images/core/README.md
  6. 11.x core/themes/starterkit_theme/README.md
  7. 11.x core/modules/package_manager/tests/fixtures/fake_site/README.md
  8. 11.x core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/project-with-illegal-dir-scaffold/assets/README.md
  9. 11.x core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/sites/default/README.md
  10. 11.x core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/README.md
  11. 11.x core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/README.md
  12. 11.x core/tests/PHPStan/README.md
  13. 11.x core/tests/README.md
  14. 11.x README.md
Same filename and directory in other branches
  1. 7.x misc/brumann/polyfill-unserialize/README.md
  2. 7.x misc/typo3/phar-stream-wrapper/README.md
  3. 9 composer/Plugin/ProjectMessage/README.md
  4. 9 composer/Plugin/Scaffold/README.md
  5. 9 core/themes/olivero/README.md
  6. 9 core/themes/claro/images/core/README.md
  7. 9 core/themes/starterkit_theme/README.md
  8. 9 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/project-with-illegal-dir-scaffold/assets/README.md
  9. 9 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/sites/default/README.md
  10. 9 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/README.md
  11. 9 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/README.md
  12. 9 core/tests/README.md
  13. 9 core/assets/vendor/modernizr/README.md
  14. 9 README.md
  15. 10 composer/Plugin/ProjectMessage/README.md
  16. 10 composer/Plugin/Scaffold/README.md
  17. 10 core/themes/olivero/README.md
  18. 10 core/themes/claro/images/core/README.md
  19. 10 core/themes/starterkit_theme/README.md
  20. 10 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/project-with-illegal-dir-scaffold/assets/README.md
  21. 10 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/sites/default/README.md
  22. 10 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/drupal-composer-drupal-project/docroot/README.md
  23. 10 core/tests/Drupal/Tests/Composer/Plugin/Scaffold/fixtures/README.md
  24. 10 core/tests/README.md
  25. 10 core/assets/vendor/modernizr/README.md
  26. 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.