Skip to content
This repository was archived by the owner on Jan 8, 2025. It is now read-only.

Third attempt at migrating to rehype#253

Merged
iAdramelk merged 8 commits intomainfrom
iadramelk/mdx-rehype-v3
Mar 20, 2023
Merged

Third attempt at migrating to rehype#253
iAdramelk merged 8 commits intomainfrom
iadramelk/mdx-rehype-v3

Conversation

@iAdramelk
Copy link
Contributor

@iAdramelk iAdramelk commented Mar 15, 2023

Because of the revert, there are a lot of files in the PR. To make the review faster, I split every new fix into separate commits and lined them below.

Changes:

#246 is not a part of this PR because it is not related to rehype migration. I will work on it separately.

@vercel
Copy link

vercel bot commented Mar 15, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated
docs ✅ Ready (Inspect) Visit Preview 💬 Add your feedback Mar 16, 2023 at 7:09PM (UTC)

Copy link
Contributor

@avatus avatus left a comment

Choose a reason for hiding this comment

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

left some comments/questions. So far, works great locally and on the deployed link.
One thing I couldn't comment on in the code was the removal of older-versions. That page was a "common" page that didn't rely on docs from the content folder. Its a way to prevent us from having to backport information that isn't version specific. I'd like to see it added back in (and there will be more pages like this soon, such as Upcoming Features, so we'd like to be able to parse any other pages that exist besides [[...slug]], although I believe that is already the case since search-results still exists.

Comment on lines +32 to +35
.next {
object-fit: contain;
}

Copy link
Contributor

Choose a reason for hiding this comment

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

this name seems a bit ambiguous. perhaps we can call the class object-contain or something, since that's all its really doing. It makes it easier to know what it's doing and makes more sense in the VideoBar component as wel

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed it


// Here we generate a list of pages to render with getStaticProps,
// in the future we may try to only generate current version and set
// `fallback: true` to increase build speed
Copy link
Contributor

Choose a reason for hiding this comment

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

slow build speed is fine if it optimizes user experience, but if the build times out from memory, we can use that solution for sure.

server/paths.ts Outdated
*/

const makeParams = (path?: string) => {
const slug = path.split("/").filter((part) => part);
Copy link
Contributor

Choose a reason for hiding this comment

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

what is the purpose of filter here if we return every element?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The original slug looks like this /var/13.x/page-name/, so we need to filter the first and the last blank segments. We could do it in the slug generation function, but then we will need to add them back to the source map and other places.

}

export const getStaticPathsForDocs = (): DocsStaticPath[] => {
const result = [];
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
const result = [];
const result: DocsStaticPath[] = [];

server/paths.ts Outdated
Comment on lines +150 to +159
result.push(
...getSlugsForVersion(version, {
ignoreLatest: true,
withNoIndex: true,
}).map(makeParams)
);

if (version === latest) {
result.push(...getSlugsForVersion(version).map(makeParams));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

does this mean if version === latest we push the result twice?

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, right now, we push twice, but I am thinking about changing it to rewrites in config instead of actual paths.

server/paths.ts Outdated
Comment on lines +181 to +186
// Add normalized paths for the current version in additon to full paths
if (version === latest) {
paths.forEach((path) => {
result[normalizeDocSlug(path, version)] = path;
});
}
Copy link
Contributor

Choose a reason for hiding this comment

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

does this overwrite a value set in the forEach loop above? We could do a conditional instead

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, it sets values twice. E. g. /docs/ and /docs/ver/12.x/. But I will also try the redirect idea so w may not need it.

.toString();

const Suite = suite("server/remark-images");

Copy link
Contributor

Choose a reason for hiding this comment

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

awesome tests!

@iAdramelk iAdramelk force-pushed the iadramelk/mdx-rehype-v3 branch from 0d71e40 to a57564f Compare March 16, 2023 15:47
@iAdramelk iAdramelk requested a review from avatus March 16, 2023 15:49
@iAdramelk
Copy link
Contributor Author

@avatus Returned older-versions page and replaced the current version solution with redirects. Please check

@iAdramelk
Copy link
Contributor Author

@avatus ok, we have a problem, lol. I remember why I removed older-versions – we already have it in the docs, so we now have a naming conflict. Will add an exception for now, but we should remove older-versions.mdx from docs.

@avatus
Copy link
Contributor

avatus commented Mar 16, 2023

@avatus ok, we have a problem, lol. I remember why I removed older-versions – we already have it in the docs, so we now have a naming conflict. Will add an exception for now, but we should remove older-versions.mdx from docs.

I can remove the older-versions.mdx from the docs folder so it doesn't conflict here. Ill PR and backport it today

};
})
...getSlugsForVersion(version)
.filter((path) => path !== "/older-versions/") // We should remove older-versions.mdx from docs
Copy link
Contributor

Choose a reason for hiding this comment

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

We can remove this check once gravitational/teleport#23192 gets pulled in. But good to know we have a killswitch for anything similar in the future. thank you!

avatus
avatus previously approved these changes Mar 16, 2023
Copy link
Contributor

@avatus avatus left a comment

Choose a reason for hiding this comment

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

Looks good to me and has been working great locally. Would wait for @alexfornuto to go over it as his comb is much more fine than mine

@alexfornuto alexfornuto requested a review from ptgott March 16, 2023 18:34
Copy link
Contributor

@alexfornuto alexfornuto left a comment

Choose a reason for hiding this comment

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

The Good

  • Local refresh - working manually, though it's a bummer that live refresh won't work.
  • Video auto playing - confirmed.
  • Images - reviewed several png and svg files, they all appear to render correctly.

The bad

  • Versioned paths - Using a versioned link for the current version successfully redirects, but using the version switcher on the page errors out:

    error - ./content/11.x/docs/pages/deploy-a-cluster/introduction.mdx
    Module parse failed: Assigning to rvalue (1:2)
    You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
    > ---
    | title: "Running a Production Teleport Cluster"
    | description: "Guides to running Teleport in production."
    

    This error can't be escaped by navigating to another page, the dev server needs to be restarted.

  • Vars - now that #254 is merged, can you rebase this branch against master to confirm that it all works when put together?

@iAdramelk
Copy link
Contributor Author

error - ./content/11.x/docs/pages/deploy-a-cluster/introduction.mdx
Module parse failed: Assigning to rvalue (1:2)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders


| title: "Running a Production Teleport Cluster"
| description: "Guides to running Teleport in production."

@alexfornuto Can please you check if you have ver folder with the mdx files inside the pages folder? If yes, can you remove them and try again? They are automatically placed in the folder by the previous build system and can break the new one.

@avatus
Copy link
Contributor

avatus commented Mar 16, 2023

FWIW, I had that same versioned pages error until I just deleted the local docs repo and recloned.

- Update to Next@13
- Add classes fro images to preserve aspect ratio
- Replace probe-image-size with image-size
- Move test to other tests location
- Move nft excludes to next.config.mjs
@iAdramelk
Copy link
Contributor Author

Ready to merge if @alexfornuto is ok with it.

@alexfornuto
Copy link
Contributor

@iAdramelk I am begrudgingly OK with it.

@iAdramelk
Copy link
Contributor Author

@alexfornuto ok, merging it then.

@iAdramelk iAdramelk merged commit 5821d58 into main Mar 20, 2023
@iAdramelk iAdramelk deleted the iadramelk/mdx-rehype-v3 branch March 20, 2023 14:08
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 22, 2023
In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 22, 2023
In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 22, 2023
In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 23, 2023
In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 23, 2023
Backports #23464

In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 23, 2023
Backports #23464

In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 23, 2023
Backport #23464

In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 24, 2023
Backports #23464

In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 24, 2023
Backport #23464

In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 24, 2023
Backports #23464

In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 24, 2023
Backports #23464

In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 24, 2023
Backports #23464

In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
ptgott added a commit to gravitational/teleport that referenced this pull request Mar 24, 2023
Backports #23464

In gravitational/docs#253, we substantially reduced the resource
consumption of docs builds. As a result, we can try building the docs as
part of the "Lint (Docs)" GitHub Actions workflow in order to prevent
build issues from breaking docs deployments.

It is currently possible to merge a docs content PR into
gravitational/teleport that can later end up breaking deployments of the
docs site, e.g., because a video ID is malformed, a code snippet label
is unsupported, etc. By building the docs during the lint job, we can
prevent this kind of thing from happening.

One complication is that the docs engine reads a `config.json` file to
match git submodule directories with version of the docs. In the
`gravitational/docs` container, `config.json` expects three submodules
pointing to three versions of the docs.

To get GitHub Actions to build a single docs version, this change
overrides the `config.json` file in the gravitational/docs container so
it only expects a single version of the docs.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants