Can't resolve child_process when using Nodemailer in Next.js

Using nodemailer in one of the pages/api routes produces the following error message:

[ error ] ./node_modules/nodemailer/lib/sendmail-transport/index.js Module not found: Can't resolve 'child_process' in 'C:\ua-demo\node_modules\nodemailer\lib\sendmail-transport'

With my understanding being that the next.js pages/api routes run in the server environment alone, it is a wonder that this error is occurring. How could this be addressed so that I can send email updates to my users?

An example has been added here at codesandbox.io. I think we need to build a copy of the program directly on a local machine to reproduce.

Nextjs issue discussion

I have discovered the source. When using Next.js, all modules including NPM packages resolving native server resources during build time need to be imported in server-side only modules. This is not as straight-forward as it sounds in a universal web application.

Doing something like the following contrived example in a universally used module will result in an error like this one: Can't resolve 'child_process' in 'C:\ua-demo\node_modules\nodemailer\lib\sendmail-transport' because child_process is a native server resource.

// send-mail/server.js
import nodeMailer from 'nodemailer';
import config from './some/nodemailer/config;

const transport = nodeMailer.createTransport( config );
const sendMail = message => transport.sendMail( message );

export default sendMail;

// send-mail/browser.js
import { post } from 'axios';

const sendMail = async ( axiosRequestConfig ) => {
    try {
        await post( axiosRequestConfig );
    } catch( e ) {
        console.error( e );
    }
};
export default sendMail;

// send-mail/index.js
import isBrowser from './some/browser/detection/logic';
import browserMailer from './browser';
import serverMailer from './server';

const mailer = isBrowser() ? browserMailer : serverMailer;

export default mailer;

Import this 'send-mail' module to your component with the belief that the browser check ensures the appropriate send-email logic at runtime. However, the build fails with a similar error to the one above. The solution here is to modify the send-mail module to defer its imports until runtime.

// send-mail/index.js
import dynamic from 'next/dynamic'; // Can also use other lazy-loading module mechanism here. Since we are building a next.js app here, why not use the one created specifically for next apps?
import isBrowser from './some/browser/detection/logic';

const mailer = isBrowser()
    ? dynamic(() => import( './server' ))
    : dynamic(() => import( './browser' ));

export default mailer;

If using webpack, we can set RUN_TARGET=BROWSER environment variable for the client-side builds and use webpack-conditional-loader to branch the code at build time instead of the dynamic runtime loading as in:

// #if process.env.RUN_TARGET !== 'BROWSER'
import serverMailer from './server';
// #endif
// #if process.env.RUN_TARGET === 'BROWSER'
import browserMailer from './browser';
// #endif
let mailer;
// #if process.env.RUN_TARGET !== 'BROWSER'
mailer = serverMailer;
// #endif
// #if process.env.RUN_TARGET === 'BROWSER'
mailer = browserMailer;
// #endif

export default mailer;

// yeilds the following after server-side build
import serverMailer from './server';
let mailer;
mailer = serverMailer;
export default mailer;

// yeilds the following after client-side build
import browserMailer from './browser';
let mailer;
mailer = browserMailer;
export default mailer;

One can also choose to remove the index.js branching, and manually import server email logic in server-side only modules and browser email logic in browser only modules. In a large application, this can become quite cumbersome if not impossible to handle. It is inadvisable to do this manually.