chore: accept pollora/query 2.0 alongside 1.x

CHANGELOG.md

@@ -13,6 +13,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - The asset classes live in their own package, [`pollora/assets`](https://github.com/Pollora/assets), which the framework requires: `AssetManager`, `AssetContainer`, `AssetEnqueuer` (`Asset::add()->container()->useVite()`), `AssetFile`, the record and the wp-admin notice of a missing build. Class names do not change. The package also resolves Vite builds without Laravel, for a classic theme, a plugin or a Bedrock site. The framework keeps what needs Laravel: the service provider, the `Asset` facade, `ViteManager` (Laravel's Vite, where `ASSET_URL`, a CDN and the application URL keep applying), `RootAssetManager` and the Laravel implementations of the package's three contracts (`ViteManagerFactory`, `RuntimeContext`, `PublicPath`)
 
 ### Changed
+- Accepts `pollora/query` 2.0 alongside 1.x (`^1.0 || ^2.0`, up from `^1.0`): the package now covers every WordPress query class, with terminal methods (`first()`, `ids()`, `count()`, `exists()`) and the documentation of each builder. Class names and the three existing facades do not change. `composer update` takes 2.0, and a project that needs 1.x requires `pollora/query` `^1.0` itself. A few fixes in 2.0 change the result of a query that used to run: `where()` followed by `orWhere()` groups the earlier clauses (`(a AND b) OR c`), `DateQuery::inclusive()` now takes effect, dates use a 24-hour clock, and an invalid `fields()`, `userPermission()` or `orderBy()` direction throws a `QueryException` instead of being ignored. The package's [upgrading guide](https://github.com/Pollora/Query/blob/2.0.0/docs/upgrading.md) lists them
 - The asset classes that left for the package no longer reach for Laravel: `AssetEnqueuer` receives the hook services, the Vite factory, the runtime and a PSR-3 logger instead of resolving them from the container, `AssetFile` is resolved through a resolver the provider sets (`AssetFile::resolveUsing()`), and `AssetManager`, `MissingBuilds` and `MissingBuildNotice` take their public directory, logger and project root as arguments. The rendered HTML of a Pollora site is unchanged, in build and while Vite runs hot
 - An `AssetEnqueuer` destroyed after its application, as in a test, no longer throws while it reports a failure of its deferred enqueue
 - The typed meta classes that will leave for `pollora/meta` no longer reach for Laravel: `MetaUiDrivers` and `MetaAccessor::extend()` take a PSR-11 `ContainerInterface` (the Laravel container is one, a driver closure receives the same object), and the key of a data object's property is derived by `Pollora\Attributes\Support\Naming` instead of `Str::snake()`. What needs Laravel moved to `Pollora\Meta\Infrastructure\Laravel`: `MetaServiceProvider`, `LaravelMetaValidator`, `TypedMetaCheck`, `MetaListCommand` and `MetaAuditCommand`. The rendered pages, the REST responses and the output of the `pollora:meta:*`, `pollora:binding:list`, `pollora:roles:*` and `pollora:doctor` commands of a Pollora site are unchanged

composer.json

@@ -47,7 +47,7 @@
         "pollora/colt": "^10.0.1",
         "log1x/sage-directives": "^2.0",
         "roots/bedrock-autoloader": "^1.1",
-        "pollora/query": "^1.0",
+        "pollora/query": "^1.0 || ^2.0",
         "spatie/php-structure-discoverer": "^2.4",
         "coduo/php-humanizer": "5.0.3",
         "nwidart/laravel-modules": "^13.0",

tests/Unit/Support/QueryFacadesTest.php

@@ -0,0 +1,49 @@
+<?php
+
+declare(strict_types=1);
+
+use Illuminate\Foundation\Application;
+use Illuminate\Support\Facades\Facade;
+use Pollora\Providers\QueryServiceProvider;
+use Pollora\Query\DateQuery;
+use Pollora\Query\MetaQuery;
+use Pollora\Query\PostQuery as PostQueryBuilder;
+use Pollora\Query\TaxQuery;
+use Pollora\Support\Facades\MetaQuery as MetaQueryFacade;
+use Pollora\Support\Facades\PostQuery;
+use Pollora\Support\Facades\TaxQuery as TaxQueryFacade;
+
+// These tests hold with pollora/query 1.x and 2.x alike: the constraint allows both.
+
+beforeEach(function (): void {
+    $this->app = new Application(sys_get_temp_dir());
+    (new QueryServiceProvider($this->app))->register();
+
+    Facade::clearResolvedInstances();
+    Facade::setFacadeApplication($this->app);
+});
+
+afterEach(function (): void {
+    Facade::clearResolvedInstances();
+    Facade::setFacadeApplication(null);
+});
+
+it('binds the post, taxonomy, meta and date queries', function (string $key, string $class): void {
+    expect($this->app->make($key))->toBeInstanceOf($class);
+})->with([
+    'posts' => ['wp.query.post', PostQueryBuilder::class],
+    'taxonomies' => ['wp.query.taxonomy', TaxQuery::class],
+    'meta' => ['wp.query.meta', MetaQuery::class],
+    'dates' => ['wp.query.date', DateQuery::class],
+]);
+
+it('resolves the post, taxonomy and meta facades to their query', function (): void {
+    expect(PostQuery::getFacadeRoot())->toBeInstanceOf(PostQueryBuilder::class)
+        ->and(TaxQueryFacade::getFacadeRoot())->toBeInstanceOf(TaxQuery::class)
+        ->and(MetaQueryFacade::getFacadeRoot())->toBeInstanceOf(MetaQuery::class);
+});
+
+it('builds the arguments of a post query through its facade', function (): void {
+    expect(PostQuery::select()->postType('page')->postParent(5)->getArguments())
+        ->toMatchArray(['post_type' => 'page', 'post_parent' => 5]);
+});