PHPackages joachim-n/drupal-core-development-project - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. joachim-n/drupal-core-development-project ActiveProject joachim-n/drupal-core-development-project ========================================= Composer project for developing Drupal core 2.0.1(2mo ago)44694↓50%12[1 issues](https://github.com/joachim-n/drupal-core-development-project/issues)[7 PRs](https://github.com/joachim-n/drupal-core-development-project/pulls)GPL-2.0-or-laterPHP Since Apr 18Pushed 2mo ago8 watchersCompare [ Source](https://github.com/joachim-n/drupal-core-development-project)[ Packagist](https://packagist.org/packages/joachim-n/drupal-core-development-project)[ RSS](/packages/joachim-n-drupal-core-development-project/feed)WikiDiscussions main Synced 1mo ago READMEChangelog (10)Dependencies (18)Versions (24)Used By (0) Drupal Core Development Composer Project ======================================== [](#drupal-core-development-composer-project) This is a Composer project template for developing Drupal core. It allows the following: - A clean git clone of Drupal core. - Composer dependencies of Drupal core are installed, so Drupal can be installed and run as normal. - Other Composer packages you might want, such as Drush, Devel module, Admin Toolbar module, and Devel Accessibility can be installed too, but don't affect the composer files that are part of Drupal core. - Contrib modules can be installed with Composer (normally Composer would refuse to install them because their info.yml file does not declare compatibility with core `main` branch). - Other packages, including contrib modules, can be installed as git clones to develop them in tandem with Drupal core. Roadmap ------- [](#roadmap) Get this into Drupal core! See . Installation ------------ [](#installation) ### Basic installation [](#basic-installation) To install a Drupal project for working on Drupal core: ``` $ composer create-project joachim-n/drupal-core-development-project ``` Composer will clone Drupal core into a 'repos/drupal' directory within the project, and then symlink that into the project when it installs Drupal core. Drupal core is checked out to its default branch, which is currently main. To start on a different branch without first checking out main, you can use the `--no-install` option with the `composer create-project` command, then change the branch of the Drupal core clone, then do `composer install`. Once the Composer installation is complete, you can install Drupal as normal, either with `drush si` or with the web UI. ### Installation on DDEV [](#installation-on-ddev) First, make sure your DDEV version is at least 1.25.0. Next, create a new folder for your project and `cd` into it. Then: ``` $ ddev config --project-type=drupal12 --docroot=web $ ddev start $ ddev composer create-project joachim-n/drupal-core-development-project ``` In case you are on a case-insensitive file system, like APFS on macOS, run: ``` git -C ./repos/drupal config core.ignorecase true ``` ### Installation on DDEV with the justafish/ddev-drupal-core-dev DDEV addon [](#installation-on-ddev-with-the-justafishddev-drupal-core-dev-ddev-addon) To use the justafish/ddev-drupal-core-dev DDEV addon, you need to make the following changes to the installation instructions for that addon: - For `ddev config`, specify --project-type=drupal - Do `composer install` before doing `ddev get justafish/ddev-drupal-core-dev` - Do `ln -s web/autoload.php .` so the addon's `ddev drupal` command find the autoloader. (There is a merge request to remove the need for this: [justafish/ddev-drupal-core-dev#35](https://github.com/justafish/ddev-drupal-core-dev/pull/35)) - DO NOT do `drupal install`. Instead, do `ddev drush si --db-url=sqlite://sites/default/files/.ht.sqlite?module=sqlite -y`(You might need to manually create web/sites/default/files first) The `drupal install` command does not work when the drupal package is symlinked in by Composer. To run PHPUnit tests, you will need to tweak the DDEV phpunit command until [justafish/ddev-drupal-core-dev#37](https://github.com/justafish/ddev-drupal-core-dev/pull/37) is fixed. Installing other packages ------------------------- [](#installing-other-packages) You can install any Composer package as you would with a normal project. This will not affect Drupal core. To work with Composer, you need to be in the root directory of the project, not in the Drupal core folders. If Drupal core is checked out at a feature branch, Composer may complain that dependencies are not met, because it does not see the feature branch as satisfying the dependency. You can either: - Temporarily switch Drupal code back to the main branch, do Composer tasks, then switch it back. - Define the version in the `repositories` section of the project composer.json. - Define a branch alias in the project composer.json. ### Installing other packages from path repositories [](#installing-other-packages-from-path-repositories) You can install additional packages from a path repository, in the same way that Drupal core is installed (although other packages will no require all the tweaks that Drupal core does!). This can be useful to develop packages and modules in tandem with core. 1. Create a git clone of the module or package. The `repos/` folder can be used for this. It's simplest to start off from a main branch so that Composer sees this as the installed version, and dependencies work properly. 2. Define a path repository for the package. See for details. 3. Do `composer require` for the package. You can now switch the package to a feature branch, such as one from a merge request, in order to work on a feature or bug. If you need to perform Composer operations, Composer may complain that the feature branch does not satisfy requirements. You can do one of: - Check out the main branch with git, perform the Composer operations, then return to the feature branch. - Define the version that Composer sees for this package by specifying the "versions" option in the declaration of the path repository in `composer.json`. ### Working with other versions of Drupal core [](#working-with-other-versions-of-drupal-core) You can change the git clone of Drupal core in `repos/drupal` to a different main branch. Prior to running `composer install` you may need to do some of the following: - You may need to delete `composer.lock`, particularly if your new version doesn't have one of Drupal core's Composer plugins which existed in your prior version. - If using DDEV, you may need to reconfigure which version of PHP it is using. Limitations ----------- [](#limitations) ### Contrib and custom tests [](#contrib-and-custom-tests) Contrib and custom module tests can't be run. For details, see [\#14](https://github.com/joachim-n/drupal-core-development-project/issues/14). ### 'Could not scan for classes' error messages [](#could-not-scan-for-classes-error-messages) During some Composer commands you may see multiple copies of this error message: > Could not scan for classes inside \[Drupal class filename\]. These are harmless and can be ignored. Developing Drupal core ---------------------- [](#developing-drupal-core) You can use the Drupal core git clone at `repos/drupal/` in any way you like: create feature branches, clone from drupal.org issue forks, and so on. Changes you make to files in the git clone affect the project, since the git clone is symlinked into it. ### Managing the Composer project [](#managing-the-composer-project) Changes to the Drupal core git clone's composer.json will be taken into account by Composer. So for example, if pulling from the main branch of Drupal core changes Composer dependencies, and in particular if you change to a different core major or minor branch, you should run `composer update` on the project to install these. ### Running tests [](#running-tests) The following are required to run tests. #### PHPUnit configuration [](#phpunit-configuration) The simplest way to run tests with this setup is to put the phpunit.xml file in the project root and then run tests from there: ``` $ vendor/bin/phpunit web/core/PATH-TO-TEST-FILE/TestFile.php ``` ##### On DDEV [](#on-ddev) 1. Copy the `phpunit-ddev.xml` file that this template provides and rename it to `phpunit.xml`: ``` $ cp phpunit-ddev.xml phpunit.xml ``` 2. Change the BROWSERTEST\_OUTPUT\_BASE\_URL value to the host URL of the project. ##### On other platforms [](#on-other-platforms) 1. Copy Drupal core's sample `phpunit.xml.dist` file to the project root and rename it to `phpunit.xml`: ``` $ cp web/core/phpunit.xml.dist phpunit.xml ``` 2. Change the `bootstrap` attribute so the path is correct: ``` bootstrap="web/core/tests/bootstrap.php" ``` ### Debugging [](#debugging) You can set up debugging in an IDE that's open at the `repos/drupal` folder, so that it recognises the process being run from the project root. For example, in VSCode, this is done as follows in the debugger configuration: ``` "pathMappings": { // Make this work with the root project. "/ABSOLUTE/PATH/TO/PROJECT/repos/drupal": "${workspaceRoot}" } ``` Technical details ----------------- [](#technical-details) The rest of this document is gory technical details you only need to know if you're working on this project template or debugging it. ### How it works [](#how-it-works) The composer.json at the project root uses a Composer path repository so that when the drupal/drupal package is installed, it's symlinked in from the Drupal core git clone, at the branch that the clone has checked out. Drupal core itself defines path repositories in its top-level composer.json. These need to be overridden in the project root composer.json so they point to inside the Drupal core git clone. Additionally, the paths to the drupal/core-recommended and drupal/core-dev packages are defined as path repositories, so that the package versions which are fixed in those metapackages are respected in the project. This means the same versions are installed as if installing Composer packages on a plain git clone of Drupal core. Contrib modules are made installable with the ComposerCoreVersionsLeniency Composer script. ### Manual Installation [](#manual-installation) Clone the repository for this template into, say, 'drupal-dev'. ``` $ cd drupal-dev # Create a folder in which to store git clones, which Composer will symlink in. $ mkdir repos $ cd repos # Clone Drupal core, to whatever branch you like. $ git clone --branch 9.2.x https://git.drupalcode.org/project/drupal.git # Go back to the project root. $ cd .. # Install packages with Composer. $ composer install ``` The Drupal core git clone will be clean apart from: ``` sites/default/settings.php vendor ``` Since it doesn't have a .gitignore at the top level, you can add one to ignore those files if you like. ### Project template development installation [](#project-template-development-installation) To test how Composer creates a new project from the template, you need a git clone of the template repository. In a separate location, do: ``` $ composer create-project joachim-n/drupal-core-development-project NEW_PROJECT_DIRECTORY --stability=dev --repository='{"url":"/path/to/git/clone/of/project/template/","type":"vcs"}' ``` ### Workarounds [](#workarounds) Several workarounds are necessary to make Drupal core work correctly when symlinked into the project. These are all taken care of by Composer scripts during installation. Details are below. Most if not all of these will no longer be needed once is fixed. #### Vendor folder [](#vendor-folder) The vendor folder has to be symlinked into the Drupal core repository, because otherwise code in core that expects to find a Composer autoloader fails. This is done by a Composer script after initial installation. The manual command is: ``` ln -s ../../vendor ./repos/drupal/vendor ``` #### App root files patches [](#app-root-files-patches) The index.php and update.php scaffold files have to be patched after they have been copied to web/index.php, because otherwise DrupalKernel guesses the Drupal app root as incorrectly being inside the Drupal core git clone, which means it can't find the settings.php file. This is done by a Composer script after initial installation. The manual commands are: ``` cd web && patch -p1