Replies: 3 comments
-
Can you provide with a guide on how did you convert your Next js project into a package ? |
Beta Was this translation helpful? Give feedback.
-
I would really like to have this 👍🏻 Reusing pages and APIs is a common problem while using Next.js in big projects. |
Beta Was this translation helpful? Give feedback.
-
Definitely a ➕ 1 to a virtual file system and this idea in general. 👍 For example, we want to provide SSO middleware to all our apps and don't want every team to have to create a route for handling the SSO callback URL, e.g. However unless there is actually a page for it in the filesystem, e.g. src/
pages/
_sso-provider/
token.jsx Then Next will always return a But just for SSO alone we have a handful of routes we want to "package" up as middleware, and the same goes for things like Health Check endpoints and other internal / operational related responsibilities of our apps. For now, we just stub these pages out like so which at least gets us a // src/pages/_sso-provider/[handler].jsx
export default function SsoHandler() {
return <> </>;
} |
Beta Was this translation helpful? Give feedback.
-
Summary
provide a way to generate an intermediate build that allows publishing NextJS pages and api routes as an NPM module. For example,
target: "lib"
innext.config.js
provide a virtual file system that allows to consume NextJS NPM modules built with
target: "lib"
and load pages & api routes virtually as if they were part of the app.For example, in your NextJS app:
And this would generate virtual pages & api routes:
@my-org/dashboard/build/pages/dashboard/index.js
@my-org/dashboard/build/pages/dashboard/login.js
@my-org/dashboard/build/pages/dashboard/users/[id].js
Background
It's currently not possible to easily create re-usable pages & api routes across multiple projects. An example of use case is a dashboard built in NextJS that has its own pages & api routes that we want to be able to "mount" in other NextJS apps. Currently, the way to do so is to manually create all api & page routes and import/re-export from the NPM module. For instance:
While this approach works, it requires to know the exact directory structure, then re-create it, and then re-export from the library. However, if any of the exports method change (e.g: from
getStaticProps
togetServerSideProps
) or if the directory structure changes, then it requires to manually do those changes over again in all projects that depend on this dashboard.Proposal
Target "lib"
NextJS should allow to set
target: "lib"
innext.config.js
which will generate unoptimized code without using env vars, other config, or triggeringget*Props
at build time, and generate pages & api routes in.next
. This project can then be published to the NPM registry and later be consumable by a NextJS virtual file system.Virtual file system
NextJS should allow to set a
virtualFileSystem
array innext.config.js
that can contain a list of NextJS NPM modules than can be "mounted" or more specifically tell NextJS to loadpages
&api
routes from an NPM module instead of the local file system. The virtualpages
&api
routes would be built using the hostnext.config.js
config.This could provide several benefits:
pages
&api
routes across multiple projectsNODE_ENV === "development"
A more realistic example, a headless CMS that could provide its dashboard as an NPM module and allow the user to implement their own pages but also manage it.
Beta Was this translation helpful? Give feedback.
All reactions