Skip to content

phpDocumentor Guides integration#200

Draft
wouterj wants to merge 31 commits intosymfony-tools:mainfrom
wouterj:phpdocumentor-guides
Draft

phpDocumentor Guides integration#200
wouterj wants to merge 31 commits intosymfony-tools:mainfrom
wouterj:phpdocumentor-guides

Conversation

@wouterj
Copy link
Contributor

@wouterj wouterj commented Nov 30, 2025

This merges the SymfonyExtension from https://github.com/wouterj/symfony-docs-guides into this project.

Todo

/*
* This file is part of the Docs Builder package.
* (c) Ryan Weaver <ryan@symfonycasts.com>
* This file is part of the Guides SymfonyExtension package.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks wrong to me.

$this->filesystem->put('index.rst', $contents);
}

#[\Override]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't use this attribute in Symfony (and Psalm has a config setting to avoid requiring its usage)

{
$this->application = new BaseApplication();
$this->buildConfig = new BuildConfig();
public function __construct(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change breaks the bin/docs-builder script currently.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@javiereguiluz is the symfony.com website using the docs-builder executable or is it using this package as a library ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use it as a library

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you share the integration code ? It would make it easier to figure out how to avoid (or at least reduce) BC breaks.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For full docs (Symfony Docs, bundles, the Symfony Book) it's basically this:

$buildConfig = (new BuildConfig())
    ->setContentDir($buildDir)
    ->setOutputDir($tempBuildDir)
    ->setImagesDir($publicImagesDir)
    ->setImagesPublicPrefix($publicImagesPrefix);

if ('symfony' === $bookSlug) {
    $buildConfig->setSymfonyVersion($branch);
}

try {
    $result = $this->docBuilder->build($buildConfig);

    if (!$result->isSuccessful()) {
        // ...
    }
} catch (\Throwable $e) {
    // ...
}

For blog posts, it's just this:

$parseResult = (new DocBuilder())->buildString($rstContents);
if (!$parseResult->isSuccessful()) {
    // ...
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wouterj this means it would be great to revert changes done to the DocBuilder public API if possible (I think we could expose the same public API than today based on top of guides) as it is the public API of this library.

Note that I don't even see where your new code uses the modified DocBuilder API (except in tests that haven't been updated and so are failing)

Copy link
Contributor Author

@wouterj wouterj Dec 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes yes. I now also have access to the code behind the symfony.com's docs rendering. So I've started working on the integration (and making the new SymfonyExtension installable is a big part of that). Small steps, but we'll get there :)

@wouterj
Copy link
Contributor Author

wouterj commented Dec 1, 2025

Thanks for the detailed review, @stof :)

This was just a blunt import of the commits I made in my test project, which I started from scratch. So the goal now is to make sure the code in this PR matches whatever we were doing in this repository before. Your comments are a great start with this, as they show some unintentionally difference that we should revert from this PR before merging.

@stof
Copy link
Member

stof commented Dec 1, 2025

The CI also tells me that existing tests must be updated (which will help avoiding regressions if they can still run)

@wouterj wouterj mentioned this pull request Mar 1, 2026
@wouterj wouterj force-pushed the phpdocumentor-guides branch from bf5952b to fa579ee Compare March 15, 2026 14:40
@wouterj wouterj force-pushed the phpdocumentor-guides branch from 86ae537 to 1682f32 Compare March 15, 2026 14:44
@wouterj
Copy link
Contributor Author

wouterj commented Mar 16, 2026

Little update after this weekend: I've applied the changes applied to this repository since starting with the guides one 2 years ago (like AI github links and code highlight changes).

I've also merged the integration test fixtures from the Guides integration and this repository. This allows you to see the differences in the output, although 99% of it is whitespace so it's very hard to review. While working on the integration, I've been very careful with updating the expected files so I'm very confident the resulting HTML is still equal.

Next up: moved to PR description

@javiereguiluz
Copy link
Collaborator

Wouter, thanks a lot for the detailed update and for all this work!

use SymfonyTools\DocsBuilder\GuidesExtension\Build\BuildEnvironment;
use SymfonyTools\DocsBuilder\GuidesExtension\Build\StringBuildEnvironment;

final class DocBuilder
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this DocBuilder class stay outside the GuidesExtension namespace ? This looks like the entrypoint using guides more than an extension of the guides library.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, for now (to easily differentiate between new and old code), I've moved everything in the GuidesExtension. But some of it will be moved back once the repository is cleaned up.

"autoload": {
"psr-4": {
"SymfonyTools\\DocsBuilder\\GuidesExtension\\": "src/GuidesExtension/src",
"SymfonyDocsBuilder\\": "src"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this SymfonyDocsBuilder namespace still used ?

},
"bin": ["bin/docs-builder"]
"scripts": {
"test": "SYMFONY_PHPUNIT_VERSION=12 simple-phpunit",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest moving away from this simple-phpunit in favor of installing phpunit/phpunit as a dev requirement, which is the recommended approach for modern Symfony projects now.
It only involves registering the SymfonyExtension explicitly in the phpunit.xml file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting, I thought we wanted to keep using simple-phpunit for libraries (especially by the Symfony team itself). But I see UX is using simple-phpunit, whereas AI is using phpunit. So we probably do not have a strict guideline on this

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use simple-phpunit in the main mono-repo because of its built-in parallelization of tests per sub-package, that is quite specific to the structure of the main mono-repo.
For other projects, the simple-phpunit script does not provide much benefit anymore. It only makes it harder to control which version of PHPUnit is used and to ensure you don't have conflicting versions of dependencies installed (reduced risk as phpunit reduced its dependencies outside phpunit/* and sebastian/*, but not void as some other packages also reuse sebastian/*).
For this case, installing phpunit as a dev requirement is simpler.

@@ -1,3 +1,5 @@
:orphan:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

! orphaned documents are not automatically detected

(probably not a major blocker: symfony.com only renders Prev/Next page links for very specific sections of the docs)

$context->getDestination()->put(
$context->getDestinationPath().'/'.$context->getCurrentFileName().'.fjson',
json_encode([
'parents' => [],
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No easy support for fetching the parent document. As far as I can find the symfony.com code, this property is never used so probably safe to ignore (cc @javiereguiluz please double check my assumption 😄)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wouterj would a proper document tree in phpDocumentor/guides help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants