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.
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.