Use scaffold plugin and composer packages from Drupal core 8.8.0

[greg-1-anderson]

The new drupal/core-composer-scaffold plugin in Drupal 8.8.x-dev works with earlier versions of Drupal as well. Here is an early pull request to demonstrate that.

Still to do:

• Investigate installing .editorconfig and .gitattributes to the project root by default in the upstream.
• Do not require web-root to be defined in the scaffold metadata; default to the parent directory of drupal/core if it is not set.
• zaporylie/composer-drupal-optimizations update https://github.com/zaporylie/composer-drupal-optimizations/pull/15/files

[greg-1-anderson]

Defaulting the location of [web-root] will not be done; see #3084369.

[greg-1-anderson]

We are working on

• https://www.drupal.org/project/drupal/issues/3084326
• https://bitbucket.org/drupalorg-infrastructure/package-generator/pull-requests/5/project-root-assets/diff

While these are merged, we still need to rewrite the corresponding metapackage. This will probably be the last time we need to rewrite a package; we won't do it any more once we have a stable alpha release.

[greg-1-anderson]

The metapackages have been rewritten.

[greg-1-anderson]

n.b: https://www.drupal.org/project/drupal/issues/3086148

The name of the scaffold metadata key in the composer.json extra section might change this week. Friday is the code freeze, so whatever is in at that point will be stable.

[greg-1-anderson]

The core Drupal issue referenced above has been merged, but the legacy scaffold assets metapackage has not been rewritten yet, so Drupal 8.7.x builds using these components will fail until this is done.

[greg-1-anderson]

OK, things should scaffold to the correct location again. I excluded a set of tests (Scaffold tests) that can't run here. We'll see if that gets us closer to passing; however, I also note that the tests are not passing on the master branch. I do wonder if running the Drupal tests is the best way to test this project. The Drupal test suite instructions specifically instruct that the tests should be run from a git clone + composer install, and not any other way. We may therefore have increasing failures when trying to run the same tests in the context of this project, simply because this is not a supported configuration for the tests. Also, those tests that do pass do not tell us that our project was assembled correctly, they only tell us that those tests will run in isolation, which is not necessarily relevant.

Perhaps we should just be satisfied with the site-install / runserver tests and not try to run the testsuite.

[greg-1-anderson]

If you are having trouble with drupal/core-recommended, see https://www.drupal.org/project/drupal/issues/3087531

[neclimdul]

I was manually testing this process to update a site. I'm having a bit of a conflict though and I'm not sure how best to resolve it.

Prior to this we used drupal/core which has ranged requirements on its packages. Projects are then in charge of managing their .lock file and any stricter versions of requirements. This is actually a contrib requirement for search_api_solr as documented in its installation guide.
https://git.drupalcode.org/project/search_api_solr#installation

composer require symfony/event-dispatcher:"4.3.4 as 3.4.99" drupal/search_api_solr

drupal/core-recommended on the other hand locks packages at specific releases. There's a lot to be said for that I'm sure but either some additional considerations need to happen or search_api_solr needs to update its installation guide because you can't run that install step with this approach because 3.4.99 != 3.4.32

[greg-1-anderson]

Projects that do not wish to use pinned dependencies may use drupal/core instead of drupal/core-recommended in their composer.json file.

[webflo]

Thanks @greg-1-anderson! Updated a few other things as well.

[jcnventura]

drupal/core-recommended on the other hand locks packages at specific releases. There's a lot to be said for that I'm sure but either some additional considerations need to happen or search_api_solr needs to update its installation guide because you can't run that install step with this approach because 3.4.99 != 3.4.32

Yes, the documentation for search_api_solr needs to be corrected to use 3.4.32 instead of 3.4.99. Otherwise, works fine.