Core Laravel Package

Getting Started

drupal/core is not a Laravel package — it's the Composer-consumable split of Drupal's /core directory. You won't composer require it into a Laravel app; you'll almost always pull it in transitively via drupal/core-recommended (or drupal/recommended-project) when scaffolding a Drupal site. Treat it as "the framework" rather than "a library."

Minimal steps to get moving:

composer create-project drupal/recommended-project my-site
cd my-site
# drupal/core is now in vendor/drupal/core

Then look, in order:

1. vendor/drupal/core/composer.json — pinned dependency ranges; this is what you fight with when resolving conflicts.
2. vendor/drupal/core/lib/Drupal/Core/ — the actual framework code (services, plugins, entity system).
3. vendor/drupal/core/modules/ — reference implementations of almost every API you'll need (node, user, field, views).
4. vendor/drupal/core/core.services.yml — the service container definition; first place to check when a service ID feels unfamiliar.
5. vendor/drupal/core/assets/scaffold/files/ — scaffold templates copied into project root by drupal/core-composer-scaffold (settings.php, .htaccess, etc.).

First realistic use case: build a custom module under web/modules/custom/ that defines a plugin (block, field formatter, or migration) and confirm it registers by inspecting the plugin manager in Drupal\Core\...\Plugin. This forces you through the container, the plugin system, and the cache clear cycle in one go.

If you're coming from Laravel: think of drupal/core as laravel/framework — it wires service providers, routing, the container, and the ORM (Entities instead of Eloquent). It is GPL-2.0, which matters if the rest of your stack is MIT/Apache.

Implementation Patterns

Composer management (the actual day-to-day surface). You rarely touch the vendored code; you manage it via Composer and patches. Standard pattern:

{
  "require": {
    "drupal/core-recommended": "^10.3",
    "drupal/core-composer-scaffold": "^10.3",
    "drupal/core-project-message": "^10.3"
  },
  "extra": {
    "drupal-scaffold": {
      "locations": {
        "web-root": "web/"
      }
    },
    "patches": {
      "drupal/core": {
        "Fix for issue xyz": "https://www.drupal.org/files/issues/....patch"
      }
    }
  }
}

Use cweagans/composer-patches for the patches block. Pin to core-recommended rather than bare drupal/core if you want Drupal's tested-version set.

Scaffolding workflow. Files like web/sites/default/default.settings.php, web/.htaccess, web/index.php, and web/robots.txt are copied from drupal/core/assets/scaffold/files/ on composer install. Don't edit them unless you're ready to commit them; if you must customize, either commit them (once they exist, scaffold won't overwrite) or set "drupal-scaffold": {"gitignore": true} patterns.

Version upgrades. Drupal 9 → 10 → 11 upgrades are driven by drupal/core-recommended version bumps plus composer update. Use drush alongside core:

composer require drupal/core-recommended:^10.3 --update-with-all-dependencies
drush updatedb
drush cache:rebuild

drush itself is separate (a contrib tool), but virtually every core upgrade workflow assumes it.

Custom module integration. A typical module's my_module.info.yml requires core and the core version:

name: My Module
type: module
core_version_requirement: ^10 || ^11

Then wire services via my_module.services.yml that reference core service IDs (e.g. @entity_type.manager, @current_user). In code, inject via Drupal\Core\Entity\EntityTypeManagerInterface etc. — not concrete classes.

Testing pattern. Core ships Drupal\Tests\* base classes (BrowserTestBase, KernelTestBase, UnitTestCase). Custom module tests extend these. Run with the bundled PHPUnit config:

vendor/bin/phpunit -c web/core/phpunit.xml.dist web/modules/custom/my_module/tests

Headless / decoupled. For Laravel-adjacent use cases, Drupal's JSON:API (core/modules/jsonapi) and the Drupal\Core\...\Controller layer can serve as a CMS backend. Point a Laravel frontend at /jsonapi. This is the least painful way to mix Drupal and a PHP framework that isn't Drupal.

Gotchas and Tips

You almost certainly can't use this inside Laravel. drupal/core assumes Drupal's bootstrap, .htaccess/webroot layout, and its own container. Loading it beside Laravel causes container, session, and autoload conflicts (both want Psr\* interfaces, both bootstrap kernels). If you need both, keep them as separate services and integrate via HTTP/JSON:API, not shared runtime.

Don't edit vendored core. Any change in vendor/drupal/core/ is lost on composer install. Fixes go through patches (cweagans/composer-patches) or upstream issues on drupal.org. This is the single biggest source of "it broke after deploy."

Scaffold ownership is a footgun. Files are scaffolded once. If you delete web/index.php and reinstall, it comes back; if you edit it, subsequent upgrades won't touch it but you've now silently diverged from core. Track scaffolded files in git and diff on composer update.

composer update on drupal/core cascades. Bumping core can require bumping symfony/*, guzzlehttp/guzzle, twig/twig, and dozens of drupal/* contrib modules. Use --with-all-dependencies (or -W) and expect to resolve conflicts. Lock file diffs on core upgrades are large; review them.

Cache is a trap. After editing anything in modules/custom/, you generally need drush cr. YAML service/plugin changes are invisible until the container cache is rebuilt. Development localsettings should enable Twig debug and disable caches:

// web/sites/default/settings.local.php
$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
$config['system.performance']['css']['preprocess'] = false;
$config['system.performance']['js']['preprocess'] = false;

Plugin annotations were replaced by PHP attributes. Core 10 deprecated annotation-based plugins; core 11 code (and the ecosystem) uses #[Block(...)], #[FieldFormatter(...)] etc. If following docs written for D8/D9, convert to attributes — the annotation reader still works in 10 but is on borrowed time.

Entity/field schema changes need update hooks. Modifying field storage after deploy requires an hook_update_N in a custom module and a drush updatedb. Core's own update system (core/modules/system/system.install and friends) is the reference pattern; copying it is often faster than reading docs.

Extension points to know: hook_ functions in a .module file (the classic API), event subscribers (Symfony\Component\EventDispatcher), plugin managers (annotated classes with @PluginManager / attribute-based), services.yml overrides via my_module.services.yml with Decorator or tag-based CompilerPass equivalents, and kernel events (KernelEvents::REQUEST in Drupal\Core\DrupalKernel). If you need to hook anything globally, there's almost always a specific kernel event or a plugin rather than a custom route.

Version pinning matters more than usual. drupal/core splits from a monorepo; drupal/core-recommended locks the transitive set that Drupal's CI tests. Using bare drupal/core instead exposes you to subtle Symfony/Twig incompatibilities that nobody upstream will help you debug.

License check. GPL-2.0 is copyleft. Pulling drupal/core into a product that isn't itself GPL-compatible is a legal question, not a technical one — worth resolving before you go further than a prototype.