Skip to content
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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

maxhr
Copy link

@maxhr maxhr commented Sep 9, 2022

Pre-flight checklist

  • I have read the Contributing Guidelines on pull requests.
  • If this is a code change: I have written unit tests and/or added dogfooding pages to fully verify the new behavior.
  • If this is a new API or substantial change: the PR has an accompanying issue (closes #0000) and the maintainers have approved on my working plan.

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

@facebook-github-bot facebook-github-bot added the CLA Signed Signed Facebook CLA label Sep 9, 2022
@Josh-Cena Josh-Cena added the pr: new feature This PR adds a new API or behavior. label Sep 9, 2022
@netlify
Copy link

netlify bot commented Sep 9, 2022

[V2]

Built without sensitive environment variables

Name Link
🔨 Latest commit cb35a1a
🔍 Latest deploy log https://app.netlify.com/sites/docusaurus-2/deploys/631b546ce196ab000881c7cd
😎 Deploy Preview https://deploy-preview-8076--docusaurus-2.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

@Josh-Cena
Copy link
Collaborator

Josh-Cena commented Sep 9, 2022

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!

@github-actions
Copy link

github-actions bot commented Sep 9, 2022

⚡️ Lighthouse report for the deploy preview of this PR

URL Performance Accessibility Best Practices SEO PWA Report
/ 🟠 74 🟢 98 🟢 100 🟢 100 🟠 80 Report
/docs/installation 🟠 79 🟢 100 🟢 100 🟢 100 🟢 90 Report

Copy link
Collaborator

@slorber slorber left a comment

Choose a reason for hiding this comment

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

Thanks, looks like a great start 👍

But there are many details I'd like to see changed 🤪


For some reason GitHub doesn't render diff properly on the CLI tests so I can't review through GitHub, will have to check the code locally 😓

CleanShot 2022-09-30 at 18 49 16@2x

versionName: string,
): string {
return path.join(
siteDir,
versionedDocsPath || '',
Copy link
Collaborator

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

Copy link
Collaborator

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. |
Copy link
Collaborator

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 || '',
Copy link
Collaborator

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', () => {
Copy link
Collaborator

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?

Comment on lines +123 to +128
/**
* 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;
Copy link
Collaborator

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)

Copy link
Collaborator

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` */
Copy link
Collaborator

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 = {
Copy link
Collaborator

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', () => {
Copy link
Collaborator

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',
Copy link
Collaborator

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 @@
/**
Copy link
Collaborator

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

@slorber slorber marked this pull request as draft September 30, 2022 16:50
@Jersyfi
Copy link

Jersyfi commented Feb 27, 2023

@maxhr @slorber is any help needed here to get progress on this PR? I need this feature to proceed with my documentation because I have several frameworks with different versioning which looks messy if they aren't in a single folder.

@slorber
Copy link
Collaborator

slorber commented Mar 2, 2023

@maxhr @slorber is any help needed here to get progress on this PR? I need this feature to proceed with my documentation because I have several frameworks with different versioning which looks messy if they aren't in a single folder.

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.

@Jersyfi
Copy link

Jersyfi commented Mar 2, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed Signed Facebook CLA pr: new feature This PR adds a new API or behavior.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants