[10.x] Fix installing DBAL on a fresh app

[timacdonald]

DBAL issue

We cannot install DBAL on a fresh Laravel application.

composer create-project laravel/laravel dbal-test
cd dbal-test
composer require doctrine/dbal ❌
composer require doctrine/dbal -w ❌
composer require doctrine/dbal -W ❌
composer require doctrine/dbal:\* ❌
composer require doctrine/dbal carbonphp/carbon-doctrine-types ✅

Framework issue: #49403

Solutions to try and make it better...

conflict

Add conflict with carbonphp/carbon-doctrine-types:^2.0

• composer update ✅
• composer update laravel/framework ❌
• composer update laravel/framework -w ❌
• composer update laravel/framework -W ❌
• composer update laravel/framework carbonphp/carbon-doctrine-types ✅

require

Add require of carbonphp/carbon-doctrine-types:^2.0

• composer update ✅
• composer update laravel/framework ❌
• composer update laravel/framework -w ✅
• composer update laravel/framework -W ✅
• composer update laravel/framework carbonphp/carbon-doctrine-types ✅

docs

We could just document that you need to composer require doctrine/dbal carbonphp/carbon-doctrine-types to install dbal, but that feels weird to me.

Why conflict

Although require offers the best user experience, we don't require this package.

• Adding a conflict will unblock new applications.
• Any long lived application is less likely to randomly need to install dbal as they likely have already had a need for it.
• We can handle incoming GitHub issues with by telling them to composer update laravel/framework carbonphp/carbon-doctrine-types

Note

I do not like any of these solutions.

Update

I've opened an issue on Carbon (briannesbitt/Carbon#2905) to ask them to make the dependency opt in.

[GrahamCampbell]

I'm not sure this is a good idea, as it will prevent people from upgrading to the newer laravel 10 versions if they already have this package installed. I'd prefer either the solution of us updating our install docs to require v2 or asking carbon to make that package optional on their side.

[timacdonald]

See briannesbitt/Carbon#2903

[GrahamCampbell]

That issue is different. I'm asking that carbon drop the dependency on their side, entirely.

[timacdonald]

@GrahamCampbell that linked issue was context for the PR, not in reply to your comment 👍

[GrahamCampbell]

Oh, sorry. Thanks. 👍

[Jubeki]

A possible solution (though more like a workaround)

composer require doctrine/dbal --no-update
composer update doctrine/dbal carbonphp/carbon-doctrine-types

[driesvints]

Talking to @kylekatarnls about alternative solutions. Gonna draft this for now.

[driesvints]

Looks like there's no other solution than this one so let's get this merged and tagged.

[kylekatarnls]

@GrahamCampbell

That issue is different. I'm asking that carbon drop the dependency on their side, entirely.

As a breaking change, this can be done in v3, for v2 either conflict here or we can narrow the version range on carbon, but not drop. This package was part of carbon itself for long but externalized (since the release of November 28th, it's not brand new) in another package to make it installable with dbal 4.

[kylekatarnls]

As a side note, the fact that composer require doctrine/dbal carbonphp/carbon-doctrine-types works shows that dependencies are actually resolvable and I'm trying to figure out why composer does not find itself this solution when asking composer require doctrine/dbal -W

[kylekatarnls]

Overall, I'm fine with the conflict solution, as it's not compatible with dbal 4, people are not able to use v3 of this package with Laravel 10 anyway so #49438 (comment) should not be a concern.

I would prefer this over narrowing carbonphp/carbon-doctrine-types range in carbon v2, but if you see any other problem adding this package in conflict, releasing briannesbitt/Carbon#2907 for Carbon 2.x is also acceptable on my side.