major: full dynamic pages and plain next.js

[ovflowd]

Description

This PR implements the Discussion started here on leaving Nextra in favour of a vanilla Next.js experience.

Truth be told, as mentioned in the discussion, we finally matured so that we don't need Nextra anymore.

This PR implements an engine that allows Incremental Builds (SSR) and full Static Builds of non-localised pages with localised context(s).

Leveraging Next.js Dynamic Routes feature (Static Paths + On-demand Static Page Generation).

This also uses MDX Remote for the compilation of MDXm for Next.js on build-time and on-demand.

How it works

• We first detect if the built environment is "static export" or regular builds (Standalone, Vercel)
• We determine if the pages should be built statically or not based on that (since with standalone/vercel we can support complete ISR for all existing pages
  • If on an ISR environment, we also support generating blog pages on-demand
  • Otherwise, we only generate all pages, excluding blog posts, as the static builds would be gigantic and too long.
  • On the ISR environment, we skip building the non-localized pages at build time to speed up the build.
• Then, when the page is requested, we load their Markdown data and then parse the Markdown source with MDXRemote
  • We add extra context (such as blog data) if needed
• The page is rendered by invoking the NextraTheme with necessary props

Related Issues

• Closes Redirection of Content through SSR/Middlewares #5404

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run npx turbo lint to ensure the code follows the style guide. And run npx turbo lint:fix to fix the style errors if necessary.
• I have run npx turbo format to ensure the code follows the style guide.
• I have run npx turbo test to check if all tests are passing, and/or npx turbo test:snapshot to update snapshots if I created and/or updated React Components.
• I've covered new added functionality with unit tests if necessary.

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
nodejs-org	❌ Failed (Inspect)			Mar 19, 2024 2:34pm
nodejs-org-stories	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 19, 2024 2:34pm

[vercel]

@ovflowd is attempting to deploy a commit to the OpenJS Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[AugustinMauroy]

Hey! That's great.
Question do we keep the contents in the page folder? Wouldn't it be smarter to make a content folder? So in the pages folder we'd only have .tsx and the md|mdx would be in the content directory. The pages folder would be the skeleton with the layouts.

[ovflowd]

Question do we keep the contents in the page folder? Wouldn't it be smarter to make a content folder? So in the pages folder we'd only have .tsx and the md|mdx would be in the content directory. The pages folder would be the skeleton with the layouts.

No, it is not smarter to have a content folder. As I mentioned before and it was documented before, for the time being, we want to keep the structure of the content/pages as much as simple and easy to understand for existing long-term contributors and newcomers.

A specific content folder brings no benefits and only adds complexity. A content folder also doesn't solve the original issue, so not even sure why you're mentioning it here.

The pages folder would be the skeleton with the layouts.

I know how this works, we did it on Gatsby a long time ago. But Next.js works differently, and even tho we could load the content dynamically only from a content folder, it is kinda anti-intuitive.

The current approach exists to support non-localized pages to have their source content to be shown and still be localised.

This works because:

• We know all the paths at build time by analysing the pages/en/** folder, with the content folder we have no idea what is the SLUG that each page should have. (Only if we adopted the same folder structure)
• We don't want to have dynamic page creation for static pages. This is an anti-pattern. The biggest purpose for dynamic pages is at the title itself "dynamic pages", not "static pages". The non-localized pages fit this criterion because they are actually dynamic because they don't exist and might change at each build (as more content gets translated).
• We want to avoid having a separation of content <> page skeleton. A page should have its content and components together. This would avoid the mess we had on Gatsby.

Also, gentle reminder that you already asked me this a few times, and I find it kinda annoying that you keep insisting on it (if that was not your intention, then I'm sorry 😅)

[AugustinMauroy]

LGTM !
Thanks Claudio for your answer.

[ovflowd]

Updates on the PR

• I've updated this PR replacing some of the existing logic for the next-data middlewares. Also note that once chore: consolidate Node releases data #5365 gets merged next-data will pretty much only be generating runtime blog data for the blog pages and the RSS feeds rebuild.
• The existing next-data folder was moved to the root next-data and the files were updated with better docs, removal of unused code, improvement of existing code
• The PR now introduces dynamic routes for blog/year-XXXX routes, instead of generating Markdown on the filesystem
• Some other minor improvements were done to performance
• Files were relinted (hence some changes purely on linting) and reformatted

[ovflowd]

cc @nodejs/website having reviews would be nice here :)

[bmuenzenmeyer]

An initial manual pass - hoping to run the code this weekend on my Windows machine

[ovflowd]

Going to rebase and update based on code-review soon.

[ovflowd]

Hey, @nodejs/website I've updated this PR and now it contains the full solution of:

• Using plain Next.js without Nextra
• Dynamic Pages
• Refactoring of next-data

Everything is working as expected now!

[araujogui]

LGTM

[bmuenzenmeyer]

I want to run the code locally again but thought I'd submit this initial review

[ovflowd]

@aymen94 I think it was premature to get such a massive PR merged without more reviews from other folks.

But I guess it's fine 😅

[aymen94]

@aymen94 I think it was premature to get such a massive PR merged without more reviews from other folks.

But I guess it's fine 😅

@ovflowd I understand your point regarding the number of reviews for merging a completely new development. While four reviews may seem like enough, I appreciate your suggestion to pay attention. 😁