phpDocumentor Guides integration#200
Conversation
| /* | ||
| * This file is part of the Docs Builder package. | ||
| * (c) Ryan Weaver <ryan@symfonycasts.com> | ||
| * This file is part of the Guides SymfonyExtension package. |
| $this->filesystem->put('index.rst', $contents); | ||
| } | ||
|
|
||
| #[\Override] |
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
This change breaks the bin/docs-builder script currently.
There was a problem hiding this comment.
@javiereguiluz is the symfony.com website using the docs-builder executable or is it using this package as a library ?
There was a problem hiding this comment.
We use it as a library
There was a problem hiding this comment.
Could you share the integration code ? It would make it easier to figure out how to avoid (or at least reduce) BC breaks.
There was a problem hiding this comment.
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()) {
// ...
}There was a problem hiding this comment.
@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)
There was a problem hiding this comment.
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 :)
|
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. |
|
The CI also tells me that existing tests must be updated (which will help avoiding regressions if they can still run) |
This will help differentiating between the Doctrine RST parser based code and phpDocumentor Guides based code for now. Once everything is cleaned up, we can flatten the structure again.
bf5952b to
fa579ee
Compare
86ae537 to
1682f32
Compare
|
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 |
|
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
is this SymfonyDocsBuilder namespace still used ?
| }, | ||
| "bin": ["bin/docs-builder"] | ||
| "scripts": { | ||
| "test": "SYMFONY_PHPUNIT_VERSION=12 simple-phpunit", |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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: | |||
|
|
|||
There was a problem hiding this comment.
! 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' => [], |
There was a problem hiding this comment.
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 😄)
There was a problem hiding this comment.
@wouterj would a proper document tree in phpDocumentor/guides help?
This merges the SymfonyExtension from https://github.com/wouterj/symfony-docs-guides into this project.
Todo
DocsKernelandDocBuilderin this repository