How to avoid executing page code during build?

[impguard]

I have a page that uses getServerSideProps. During dev time, this works fine. I expect the code to be executed for each page request, as an SSR page should.

However, during build time using next build, my build fails because it seems like during the "automatic optimization" stage, next decides to execute my page code. This fails due to the fact that the page automatic pulls in my database and creates a connection.

This is due to the fact that my database module roughly looks like:

import mysql from "mysql"

const pool = mysql.pool({ database settings })
// The above fails because if executed during build time, there's no database.

export default pool

As a result, during build time, I fail to build my app because it cannot connect to the database. Why is this the case? I would assume by opting into server side rendering I shouldn't be executing code during build time? Is there a way to mark this as such or do I have to create workarounds of initializing my database separate from import?

[impguard]

Still wondering if this is an improvement or something I'm thinking about wrong.

For what it's worth, I chose to wrap some of the failing code (config getting, database initialization) in a try catch to allow the build to pass, though it now spews a bunch of error logs that are safe to ignore, which is pretty terrible. Regardless, the build passes because it can now execute the code and it works in live because setting up the connection/getting configs works as intended.

Pretty bad workaround for bigger projects though, since your app now doesn't follow crash early, crash hard methodology and will safely startup without configs/databases until something else fails down the line.

[jamesmosier]

Hi @impguard. Do you have a small example of your code to make sure I'm following along? I have some code written in getServerSideProps and during builds it is not run.

[impguard]

My bad, I can see how it would be confusing. I can't provide a full sample, but here's an example:

import database from "./database"

export const getServerSideProps = async () => {
  const data = await database.getData()
  
  //...other things...
}

The function getServerSideProps isn't executed, but the file is run. I believe it's due to the fact that Next.js evaluates the script to find getServerSideProps to know not to optimize my code. However, when running the script, the import picks up my database. Which might look like this:

// database.js

const database = connectToDatabaseOrFail()

Which causes an exception during the nextJS build. I use database here because it's easy to understand, but in reality my project check some initial settings on startup and if those fail, failing fast is what I would prefer. My workaround is to forgo that, but I was wondering if there was a different workaround I didn't consider.

Alternatively, if there was an "init" function that NextJs would guarantee is called once on the server at launch, I could use that too and wrap all my singleton-esque services into that init. But, again, not preferable.

[jamesmosier]

I'm not sure if global singletons can be relied upon. From most examples I see, developers open and close connections as needed. So making whatever is exported a function that is only executed inside getServerSideProps would possibly solve this. Next doesn't work like a traditional Express or Node app, so having a reusable global singleton may lead to unexpected results.

[impguard]

Ah, I guess I should have used a different example. As I noted, I used a database since it was easiest to explain.

Another example of this causing a problem is depending on environment variables at runtime. We inject environment variables to configure the app (12 factor app and whatnot). On startup, if the environment variables aren't found or are misconfigured, we error out.

Similar problem here, because those environment variables don't exist at build time. Again, we could either inject arbitrary values to get it to pass (though it would be hard in my case, because env variables specify a config to load...which doesn't exist at build time) or have a flag to skip the check.

Now that I say this however, I guess I could have an environment variable that skips runtime checks that's set only at buildtime. Makes the code a bit more verbose but might be best of all worlds.

[bobaaaaa]

I had a similar situation in my project. My recommendation:

const database = () => connectToDatabaseOrFail();

Or use a dynamic import:

export const getServerSideProps = async () => {
  const database = await import('./database');
  const data = await database.getData()
  
  //...other things...
}

[impguard]

yea, that was one solution, which may be better than the solution I currently have. It's a bit ugly however, due to having a dynamic import or requiring dependencies to be lazily loaded which goes against some best practices around failing early and failing fast.

[bobaaaaa]

Yes I agree with you. This is why I converted the instance to a fn.

[deadcoder0904]

I went with a simple solution of doing this on every route that calls a database:

export const dynamic = 'force-dynamic'

[tobyscott25]

Legend, this fixed it for me too. Thanks.

[GiovanniColonni]

Thanks for the answer, is there a solution to skip this phase of the build completely? Because even with this export situations like top-level code are not avoided, for example during build the code:

export const dynamic = 'force-dynamic'

console.log("This log is visible during build phase")

if(!process.env.VAR){
   throw new Error("This makes the build fail") // even if it should not since dynamic (???) 
}

Maybe I am missing something but I don't find a way to solve this problem if not re-writing the code in a way that does not fail if executed out of execution context (ex build phase of a CI/CD)

[nicholas-johnson-techxcel]

Can we please stop Next.js executing our code during build?