Debug mode

[eric-burel]

Is your feature request related to a problem? Please describe.
I am using a rather complex setup:

• Jest, TypeScript, Storybook, Cypress, custom webpack for isomorphic development
• A Lerna monorepo (but NOT local to my Next app, that's a set of various packages related or not to Next)
• Local packages, using the same prefix as Lerna packages, and a Webpack alias to load them

I am hitting this issue: vercel/next.js#17262, I can't have process.env to be correctly transpiled.
I think that I should provide Next specific plugins as raw packages instead of building them and then publishing, and expect end users to use next-transpile-modules.

But I suspect that my package is not even transpiled in the first place. If I had packages that do not exist in the first place, I don't see if they are actually transpiled.

Describe the solution you'd like
Calls to debug everywhere :)

[martpie]

Hello there 👋

My recommendation regarding env vars has always been "use them at runtime, not build time".

Here's how I usually use them:

publicRuntimeConfig: {
  BASE_URL: process.env.BASE_URL,
  SERVICE_STUFF_URL: process.env.SERVICE_STUFF_URL,
  ENABLE_CIMODE:
    process.env.ENABLE_CIMODE === 'true' ||
    process.env.NODE_ENV !== 'production',
},

Then, from any file:

import getConfig from 'next/config';

const { SERVICE_STUFF_URL } = getConfig().publicRuntimeConfig; 

The reason why is I have multiple environments (dev, staging, prod...), and I need to update these values for each environment, but with a single build.

Is that of any inspiration to you?

Calls to debug everywhere :)

What do you mean?

[martpie]

That said, this is an interesting problem, I am not sure if this is in scope of this plug-in, but I'd be curious to know how you managed to fix it.

[eric-burel]

Public runtime config can be problematic in Next as you lose the serverless target and they are not really recommended, I need to keep the code as generic/"raw Next" as possible. I am not fond of Next config system anyway, I don't see the point of making it runtime only, I would rather use node-config (I come from Meteor where you use a file based config system).

By call to debug I mean more precisely we should have messages about whether the node modules were found, and whether they are transpiled or ignored. Currently, if I try to transpile "whatever-module" that do not even exist, I don't get any message, so I can't tell whether my module is actually being transpiled or not. But the code is run, because if I put 42 it will fail as it is not a string.

They way I understand it, next-transpile-modules will kind of include my NPM package into the normal Next build? So I guess that should include the magic process.env replacing client-side?

In the meantime, my solution is just to not publish those packages on NPM, I just store them in my Next boilerplate. I publish only actual, non-specific to Next NPM packages. I think there should be more official guidelines about publishing packages for Next (vercel/next.js#9133 (comment))

[martpie]

Ah, I see. A debug mode could be interesting, but it will be really verbose in the console (you'll have thousands of modules displayed).

What I could is only list the modules that are transpiled. Any preferences?

They way I understand it, next-transpile-modules will kind of include my NPM package into the normal Next build? So I guess that should include the magic process.env replacing client-side?

Yes and no. What the plugin does is tell Webpack/Babel to not ignore some directories in node_modules when transpiling files (it's ignored by default for obvious performances reasons).

I have no idea of the incidence on process.env, I would need to dig the Babel config of Next.js a bit more, but I think this is something that should be done by this plugin (if possible) (I need to think a bit more on this)

[eric-burel]

Thanks! Yeah that's what I thought, just displaying the transpiled modules specified in the options, that are actually found by your plugin. I didn't dig the code that much to be fair, as I have a workaround for now, we don't expect an usage at scale of those Next packages until a few months.

[martpie]

Fixed in #132

It's noisy, but convenient. If you would like to see other things logged, don't hesitate to open a PR or open a new issue 👍