Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
e8f505e to
0d71e40
Compare
avatus
left a comment
There was a problem hiding this comment.
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.
| .next { | ||
| object-fit: contain; | ||
| } | ||
|
|
There was a problem hiding this comment.
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
|
|
||
| // 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 |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
what is the purpose of filter here if we return every element?
There was a problem hiding this comment.
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 = []; |
There was a problem hiding this comment.
| const result = []; | |
| const result: DocsStaticPath[] = []; |
server/paths.ts
Outdated
| result.push( | ||
| ...getSlugsForVersion(version, { | ||
| ignoreLatest: true, | ||
| withNoIndex: true, | ||
| }).map(makeParams) | ||
| ); | ||
|
|
||
| if (version === latest) { | ||
| result.push(...getSlugsForVersion(version).map(makeParams)); | ||
| } |
There was a problem hiding this comment.
does this mean if version === latest we push the result twice?
There was a problem hiding this comment.
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
| // Add normalized paths for the current version in additon to full paths | ||
| if (version === latest) { | ||
| paths.forEach((path) => { | ||
| result[normalizeDocSlug(path, version)] = path; | ||
| }); | ||
| } |
There was a problem hiding this comment.
does this overwrite a value set in the forEach loop above? We could do a conditional instead
There was a problem hiding this comment.
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"); | ||
|
|
0d71e40 to
a57564f
Compare
|
@avatus Returned |
|
@avatus ok, we have a problem, lol. I remember why I removed |
a57564f to
6d6e6d5
Compare
I can remove the |
| }; | ||
| }) | ||
| ...getSlugsForVersion(version) | ||
| .filter((path) => path !== "/older-versions/") // We should remove older-versions.mdx from docs |
There was a problem hiding this comment.
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
left a comment
There was a problem hiding this comment.
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
left a comment
There was a problem hiding this comment.
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?
@alexfornuto Can please you check if you have |
|
FWIW, I had that same versioned pages error until I just deleted the local docs repo and recloned. |
This reverts commit 04f39e8.
- 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
|
Ready to merge if @alexfornuto is ok with it. |
|
@iAdramelk I am begrudgingly OK with it. |
|
@alexfornuto ok, merging it then. |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
getServerSidePropsmay be impossible or pretty hard. Commit: 9e8b835probe-image-sizelibrary with theimage-sizelibrary used by Next.js itself. 9264aac/ver/<version>#243 - Make current version URLs with/ver/x.xwork via redirects. Commit: 64f39d8Varcomponent hydration problem. Commit: 22ab61e#246 is not a part of this PR because it is not related to rehype migration. I will work on it separately.