-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(content-docs): versionedDocsPath config for docs plugin #8076
base: main
Are you sure you want to change the base?
Conversation
✅ [V2]Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
Wow, that's a big one (I know, probably a lot of test files). I'm quite busy these days and will be slow at getting to it, while @slorber is on holiday till the end of this month (and he needs to be the one to approve new public API surface). Sorry if we are slow to review–we will eventually give feedback! |
⚡️ Lighthouse report for the deploy preview of this PR
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
versionName: string, | ||
): string { | ||
return path.join( | ||
siteDir, | ||
versionedDocsPath || '', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather avoid such default values scattered in multiple places: move them to option normalization process or even better option defaults
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If versionedDocsPath should remain undefined in option, I'd rather have a getVersionedDocsPath(siteDir, versionedDocsPathOption)
to apply the fallback in a single place
@@ -34,6 +34,7 @@ Accepted fields: | |||
| Name | Type | Default | Description | | |||
| --- | --- | --- | --- | | |||
| `path` | `string` | `'docs'` | Path to the docs content directory on the file system, relative to site directory. | | |||
| `versionedDocsPath` | `string` | `undefined` | Path to the versioned docs content directory on the file system, relative to site directory. This is where the CLI command `docusaurus docs:version 1.2.3` will write the files to. The default is the site directory. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was not clear to me at all reading this doc that the default value is not website/versioned_docs
but rather simply website
and that it affects where both versioned_docs
and versioned_sidebars
will be written.
Wondering if it wouldn't be better to have 2 standalone options to give more flexibility? 🤷♂️
versionName: string, | ||
): string { | ||
return path.join( | ||
siteDir, | ||
versionedDocsPath || '', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what if the user provides an absolute versionedDocsPath
?
@@ -758,4 +758,136 @@ describe('readVersionsMetadata', () => { | |||
); | |||
}); | |||
}); | |||
|
|||
describe('versioned site with custom versions dir, pluginId=community', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels overkill to add all these new tests just for testing that particular case: lots of boilerplate for little being tested
Why not simply creating a new entry
it('works with relative versionedDocsPath', async () => {
const {defaultOptions, defaultContext, vCurrent} = await loadSite();
const versionsMetadata = await readVersionsMetadata({
options: {...defaultOptions, versionedDocsPath: './community-versions'},
context: defaultContext,
});
expect(versionsMetadata).toEqual([
{
...vCurrent,
contentPath: "...",
sidebarFilePath: "...",
},
]);
)}
This should test it without so much ceremony
Also please test with absolute paths?
/** | ||
* Path to the versioned docs content directory on the file system, relative to site | ||
* directory. Running the tagging script `docusaurus docs:version X` will generate | ||
* the files in this directory. The default is the site directory. | ||
*/ | ||
versionedDocsPath?: string | undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again not 100% agreeing with the comment: Docusaurus won't generate files in this directory but rather in 2 subdirectories of this directory (as far as I understand it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And if absolute paths are not supported, option validation should reject it. But absolute paths should probably be supported
addPluginIdPrefix(VERSIONED_DOCS_DIR, pluginId), | ||
`version-${versionName}`, | ||
); | ||
} | ||
|
||
/** `[siteDir]/community_versioned_sidebars/version-1.0.0-sidebars.json` */ | ||
/** `[siteDir]/[versionedDocsPath]/community_versioned_sidebars/version-1.0.0-sidebars.json` */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment assumes the path will be relative. Maybe it will be absolute in which case we don't need the [siteDir]
prefix.
Maybe the siteDir
does not need anymore to be passed to this function? path.join(versionedDocsPath,...rest)
could be enough?
* LICENSE file in the root directory of this source tree. | ||
*/ | ||
|
||
module.exports = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what's the purpose of this empty-site-2: in which test is this used?
@@ -584,6 +584,119 @@ describe('versioned website (community)', () => { | |||
}); | |||
}); | |||
|
|||
describe('versioned website (community) with custom versions dir', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about having a parametrized loadSite({versionedDocsPath: "community-versions"})
?
Wonder if it wouldn't simply our test a bit as you could reuse the loadSite()
that already existed in the other describe?
I guess the initial idea was to have 1 describe per site fixture
options: { | ||
id: 'community', | ||
path: 'community', | ||
versionedDocsPath: 'community-versions', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe make the path more explicit? like community_custom_versioned_docs_path
?
Having a site with multiple versionedDocsPath (default + this one) is already a bit hard to reason about, there's a chance in 1 year I get really confused by all this 🤪
@@ -0,0 +1,16 @@ | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really like the name versioned-sites-2
: when browsing that doc, I have no idea why there is a "2" in the name and what's the purpose of this fixture.
Please make it explicit, maybe rename versioned-sites-2 to versioned_docs_path_fixtures
or something? don't hesitate to nest the site + its associated content in a subfolder so that we understand this association better
I left a review that wasn't handled yet and should focus on other PRs (notable MDX2 upgrade). If @maxhr doesn't want to finish this PR, you can probably fork his branch (so that @maxhr remains credited for his work), continue the work, handle my review, and open a new PR that I can review. |
@slorber i will take a close look at this PR if it makes sense for me to fork it. Otherwise i will request my own PR. |
Pre-flight checklist
Motivation
Addresses #8061 where you can configure a directory to write the versions to when running
docusaurus docs:version
.A new parameter in content-docs plugin config
versionedDocsPath
, by default it's undefined and we use the current behavior and write versions to site dir.It supports one
versionedDocsPath
per plugin instance, but not dirs per-version as described in the issue.Test Plan
Added unit tests for new configuration.
Test links
Deploy preview: https://deploy-preview-_____--docusaurus-2.netlify.app/
Related issues/PRs