Contrib.social

Exclude development libraries from templates' composer.json by default

Open on Drupal.org →
Created on 8 October 2019, about 5 years ago
Updated 30 January 2023, almost 2 years ago

Problem/Motivation

The Drupal template projects (drupal/recommended-project and drupal/legacy-project) include dev dependencies in their composer.json file in the repository. Drupal infrastructure automatically removes these when running the subtree split for any tag (e.g. 8.9.0-alpha1), but allows them to remain for branches (e.g. 8.9.x-dev).

Proposed resolution

This behavior may be good enough. We could also consider removing the dev dependencies from the repository for 9.x.

Remaining tasks

We should update the documentation to clearly describe the situation.

User interface changes

None.

API changes

None.

Data model changes

None.

Old Summary

On the production server, and as a site builder, you shouldn't need the development libraries. So I suggest that development libraries are not included by default in Drupal core. Also, in that way the --no-dev and --update-no-dev parameters are no longer necessary for everyday-site-building.

How to create and manage a project without development libraries in the new version 8.8, where -n equals --no-interaction:

$ composer create-project drupal/recommended-project:^8.8@dev -n --no-dev mysite
$ composer update --with-dependencies --no-dev
$ composer require --update-no-dev drupal/admin_toolbar

On one hand, adding the developer tools project with for example a command like composer require drupal/devtools will be an extra step for Drupal developers, who are deep in the code. On the other hand, the benefits for those who mostly don't need these tools, like new Drupal users, site builders and dev ops people, there will be benefits. For example for dev ops people, the reduced complexity will mean less risk of unforeseen Composer events during a security update situation, like a lingering git commit blocking everything, which can grind the process down to a halt.

If the composer update --with-dependencies process breaks down, while applying late night security updates, having to debug why it happens, while under the the pressure of rolling out updates is not optimal, and might make dev ops people a little less fond of Drupal in the long run. Running composer update should be as boring a non-event as possible, and the chances of a smooth process should be maximized, by getting potential obstacles out of the way.

While there "shouldn't" be a problem, stuff happens, like with .git repository should not be included with composer package 🐛 .git repository should not be included with composer package Fixed , where rfay comments:

This seems to break every composer update I do, have to remove the coder directory in vendor to fix.

Changing to a default installation, without dev dependencies

Pros

  • For new Drupal users there will be less moving parts and reduced complexity
  • No need to remember to use --no-dev and --update-no-dev
  • You don't get a screen load of updates, and changed composer.json if you forget to add --update-no-dev
  • Composer can calculate dependencies faster during composer update
  • Less risk of unforeseen Composer events, like a lingering git commit blocking composer update
  • Less changes in composer.lock, giving less results running git diff and better overview

Cons

  • The work involved in containing the developer tools in its own drupal/devtools project
  • Developers have to run composer require drupal/devtools

Statistics

Result with --no-dev, 53 packages

$ composer create-project drupal/recommended-project:^8.8@dev -n --no-dev mysite
Installing drupal/recommended-project (8.8.x-dev 995d694d3cf9c0863bb170e7c62c8f1aa6d35437)
  - Installing drupal/recommended-project (8.8.x-dev 995d694): Cloning 995d694d3c from cache
Created project in mysite
Loading composer repositories with package information
Updating dependencies
Package operations: 53 installs, 0 updates, 0 removals
  - Installing composer/installers (v1.6.0): Loading from cache
...

Stats: 24.534 items (and 91 hidden), totalling 391,2 MB

Result without --no-dev, 106 packages

$ composer create-project drupal/recommended-project:^8.8@dev -n mysiteDEV
Installing drupal/recommended-project (8.8.x-dev 995d694d3cf9c0863bb170e7c62c8f1aa6d35437)
  - Installing drupal/recommended-project (8.8.x-dev 995d694): Cloning 995d694d3c from cache
Created project in mysiteDEV
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 106 installs, 0 updates, 0 removals
  - Installing composer/installers (v1.6.0): Loading from cache
...

Stats: 29.914 items (and 208 hidden), totalling 414,8 MB

Release notes snippet

Development dependencies have been removed from the Composer Template Projects. See the change record → for information on how to add development dependencies. It is recommended to only install development dependencies in development environments.

📌 Task
Status

Needs work

Version

9.5

Component
Composer  →

Last updated about 15 hours ago

No maintainer
Created by

🇩🇰Denmark ressa Copenhagen

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    needs-review-queue-bot

    The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

    Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

  • Comment almost 2 years ago →
    🇺🇸United States mile23 Seattle, WA

    The current behavior is that for dev branches, the project templates include drupal/core-dev as a require-dev. For tagged releases, drupal/core-dev is excluded.

    Release:

    % composer create-project drupal/recommended-project:@stable
Creating a "drupal/recommended-project:@stable" project at "./recommended-project"
Installing drupal/recommended-project (10.0.2)
  - Installing drupal/recommended-project (10.0.2): Extracting archive

[...]

% cd recommended-project 
% composer show "drupal/core-*"
drupal/core-composer-scaffold 10.0.2 A flexible Composer project scaffold b...
drupal/core-project-message   10.0.2 Adds a message after Composer installa...
drupal/core-recommended       10.0.2 Core and its dependencies with known-c...

    Dev:

    % composer create-project drupal/recommended-project:@dev 
Creating a "drupal/recommended-project:@dev" project at "./recommended-project"
Installing drupal/recommended-project (10.1.x-dev f2de0da24e4fdae1ae8b81d2f4f3fbd038809017)
  - Downloading drupal/recommended-project (10.1.x-dev f2de0da)
  - Installing drupal/recommended-project (10.1.x-dev f2de0da): Extracting archive

[...]

% cd recommended-project 
% composer show "drupal/core-*"
drupal/core-composer-scaffold 10.1.x-dev 14db477 A flexible Composer projec...
drupal/core-dev               10.1.x-dev a6812ad require-dev dependencies f...
drupal/core-project-message   10.1.x-dev 59b4475 Adds a message after Compo...
drupal/core-recommended       10.1.x-dev 3981ea2 Core and its dependencies ...

    So in the meantime we split the difference: Releases don't risk including dev requirements by default, while dev setups include the dev tools.

    The question then becomes: Should we exclude the dev tools from the dev project, and it's either +1 for consistency, or -1 for not letting users decide to take fate into their own hands by using @dev without having to type composer require drupal/core-dev

    I think I'm +1 for consistency, where we just never add drupal/core-dev to the project templates, and we tell users to add the package they need. Obviously real actual maintainers might have a different view. :-)

    Since we have a CR, setting the issue to target Drupal core 10.1.x.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024