3

I'm using drupal-composer/drupal-project.

With that, installer-paths in composer.json installs core in web/core, it doesn't clone a full git repository.

I'd like a full repository, so I can reroll a patch for core on my dev site, within the project it will be used on, without having to clone https://git.drupal.org/project/drupal.git and configure an entirely new project…

Is this even possible?

i.e. a modification to composer.json that will install core (or anything else for that matter) as a fully functional repository (i.e. with .git directories) - so you can create new branches, run diffs against to generate patches, and so on.

Improve this question
3
  • 1
    Disagree with this being off-topic. I have done core patches against a site-dev environment in cases where that was the only place I could reproduce a bug (ie, against a cloned production install).
    – mpdonadio ♦
    Jan 7, 2019 at 23:53
  • @mpdonadio And how did you set that up exactly? What Composer commands did you run to get there?
    – colan
    Mar 19, 2019 at 20:47
  • @colan You do composer require cweagans/composer-patches and then you can add a patches section to your composer.json. Look at github.com/contentacms/contenta_jsonapi/blob/8.x-3.x/… as an example.
    – mpdonadio ♦
    Mar 19, 2019 at 22:21

1 Answer 1

Reset to default
4

I'm providing an answer to this even though it's probably off-topic and I have a heavy bias here.

For core development we shouldn't use a composer-based install pattern such as drupal-composer/drupal-project because we're modifying the software project itself. Generally composer require or create-project or init is used when we want to create a new library, project or piece of software and dependencies to it, but not when working on an existing library or framework.

  1. At the moment the best way to get started if you are new to core development is to visit https://drupal.org/tools. Use either the ResilioSync option or download the latest quicksprint tools release instead. This is the tool set that the Core Mentoring program currently uses to get started from scratch.
  2. This isn't the only place/work flow for core development. Many of the core/strategic initiatives, or working groups within core development, may have a preferred development environment. For instance the Javascript Modernization Initiative has excellent documentation for their unique work flow and challenges.
  3. Of course, if you already have an environment, then cloning the repository and running composer install works as well.
  4. Finally if Composer piques your interest, the Composer Initiative (this is probably only relevant from 2019-2021) may change the way that we can work on core. And this could be a way to contribute and answer your question.

Please ask any questions you might have in #contribute on Drupal Slack or in one of the contribution channels on either IRC or Drupal Chat.

Improve this answer
1
  • Following-up, #4 didn't really pan out. Working with core is still about cloning and running composer install.
    – mradcliffe
    Feb 20, 2020 at 15:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.