Hi there,

The error you're seeing is indeed a Webpack error, and it's typically related to an imported module (in this case, related to node-pre-gyp and subsequently, sqlite3) which seems to be trying to include an HTML file. This is something Webpack doesn't know how to handle by default.

Here's how to tackle the issue:

Server-side Only Code:
The most important thing you need to realize is that libraries like sqlite3 should not be bundled with the frontend code because they are meant to be used server-side only. So, the first thing to do is make sure you're not importing or using them in any client-side code. You mentioned ./src/app/page.tsx in your import trace - ensure that you're not directly or indirectly importing server-side modules here.

Webpack Externals:
If you are sure that you're using the sqlite3 library server-side only, you can tell Webpack not to bundle it (and related libraries) by using the externals configuration. With Next.js, you can modify your next.config.js:

module.exports = {
  webpack: (config, { isServer }) => {
    if (isServer) {
      config.externals = ['sqlite3', '@mapbox/node-pre-gyp', ...config.externals];
    }
    return config;
  },
};

This configuration tells Webpack not to bundle these modules when compiling the server-side code.

Dynamic Imports:
Another tactic is to use dynamic imports with next/dynamic for code paths that might touch server-only code. This way, they won't be included in the initial client-side bundle.

Optional:
There seems to be an issue with node-pre-gyp trying to load an HTML file, which is odd for server-side libraries. Consider checking the versions you're using and see if there's a newer version without this problem. If not, it might be worth checking with the library maintainers.

Lastly, always ensure you're segregating your server and client logic. Directly importing server-side logic into your components will lead to these types of issues.

Hi @Abyssinian, great answer.

The src/app/page.tsx file looks as follows:

import TodoList from '@/app/_components/TodoList'
import { serverClient } from '@/app/_trpc/serverClient'

const Home = async (): Promise<JSX.Element> => {
  const todos = await serverClient.getTodos()
  return (
    <main className="max-w-3xl mx-auto mt-5">
      <TodoList initialTodos={todos} />
    </main>
  )
}

export default Home

This is a server component, while the TodoList is the client component which has 'use client' and uses the TRPC client library (with react query) and a hook to fetch the data from the TRPC api route.

So it should be bundling that only in the server code. At least, that's the plan.

Is there any way to check if the error is generated by the server or the client bundle?

Ah, I see. If 'Home' is intended to be a server component, then there are some issues in the way you've structured it.

Server components should not directly run side-effects like fetching data within the component body. The fetching should be done outside the component.

Here's a refactored version that works more in line with the Next.js data fetching method:

In this version, the data-fetching is moved to the getServerSideProps function, which is Next.js's way to fetch data server-side and pass it as props to the component. The component itself remains pure and only handles rendering.

This ensures that the side effect of fetching todos is performed on the server-side only and will not be bundled into the client-side code. This should prevent any client-side bundling of server-only code.

I'm using Next.js version 13 which allows async data fetching in server side components

And there's no more getServerSideProps in Next 13

hmmm. I'm very new to NextJS 13 as well (I have a post above too), so I'm not exactly sure on this one. But I do know that you can distinguish between client and server-side errors:

1. Console Output:
In next build or next dev, errors after Compiling server... are server-side; after Compiling client... are client-side.

2. .next Folder:
Errors in .next/server are server-side.
Errors in .next/static are client-side.

3. Isolate Builds:
Modify next.config.js to skip server or client bundling temporarily to identify error origin.

The error's context during build can hint at whether it's server or client-side. Ensure server-side modules are imported only in server-side code.