[Bug]: Console Ninja source gets bundled with production source when bundling with Webpack and Babel

[Poolshark]

What happened?

When creating a production bundle, utilising Webpack Babel, some Console Ninja source becomes part of the final bundle source.

Version

v1.0.294

Steps to reproduce (or sample repo)

I have created a sample repo to reproduce

1. Clone repo
2. Run bun install
3. Run bun run webpack --config webpack.config.ts
4. Check file dist/index.js

Log output

There is no log output since it only affects the bundle.

[smcenlly]

Please note, this is mentioned in our README.md:

Console Ninja detects if you are running your tool in production mode (by checking CLI flags and process environment variables).

When production mode is detected, the tool will not modify your application code even if Console Ninja is running.

In the (unlikely) case that you are running production builds on your local dev computer and are deploying or sharing local builds outside of your machine, we recommend running the Console Ninja Pause command in your editor prior to running your build to guarantee that no instrumented code ends up in your production code.

---

Your sample repo does not have any scripts in the package.json, so we're not exactly sure how to distinguish production vs. dev mode in your case. Right now, we detect that webpack is being used for a production build based on the following:

1. NODE_ENV environment variable is set to PROD or PRODUCTION (is case insensitive)
2. REACT_APP_ENV environment variable is set to PROD or PRODUCTION (is case insensitive)
3. Arguments used to run webpack include production
4. 2nd argument used to run webpack is build

Besides your sample repo, are you using a specific framework? If so, we're happy to take a look and identify how production builds are recognised. If you are not using a specific framework, in your case we recommend setting the NODE_ENV environment variable to PROD before running your build.

[smcenlly]

I'm assuming our response fixed your problem. Please let us know if you're using a specific framework and we'll investigate whether we can automatically detect and disable Console Ninja for production builds vs. dev time.

[Poolshark]

Sorry, did not have time for an earlier response.

However, thanks for your very quick reply and for your detailed explanation of how to fix the issue.

Very much appreciated! 🙌

Unfortunately, the sample repo is exactly how our production repo works. You do not always need scripts in your package.json and even if you do have, it would contain some sort of build command it would be exactly the one I have stated in the Readme:

bun run webpack --config webpack.config.ts

So, a corresponding scripts entry would be :

// package.json

...
"scripts": {
  "build": "bun run webpack --config webpack.config.ts"
}

The production flag is defined directly inside webpack.config.ts which obviously does not trigger Console Ninja's PROD detection.

// webpack.config.ts

const configurationBuilder = () => {
  return {
    mode: "production",
    ...
  }
};

export default configurationBuilder;

In the (unlikely) case that you are running production builds on your local dev computer and are deploying or sharing local builds outside of your machine, we recommend running the Console Ninja Pause command in your editor prior to running your build to guarantee that no instrumented code ends up in your production code.

No offense, nut why would this be "unlikely"? Maybe I'm wrong but I think that basically every package developer will do so before deploying to NPM. And yes, we build our apps locally since it's about 100x faster than any CI/CD and we can utilise additional tools during the build steps much more easily.

However, I really respect the work you have put into this VS Code extension but to be honest, I was not aware that extensions in general could potentially be a vulnerability (not that you's is in any way!).

Let me know if there is anything else I could help with!

[smcenlly]

The production flag is defined directly inside webpack.config.ts which obviously does not trigger Console Ninja's PROD detection.

Thanks for pointing this out. To date, we've been relying on the mechanisms used by tools/frameworks that run webpack vs. configuring webpack directly. We agree that Console Ninja should detect this case and will add support for detecting this case next week.

No offence, but why would this be "unlikely"? Maybe I'm wrong but I think that basically every package developer will do so before deploying to NPM. And yes, we build our apps locally since it's about 100x faster than any CI/CD and we can utilise additional tools during the build steps much more easily.

While local builds offer speed and flexibility, they can introduce variability into the build process outside of your control. This could be node version differences, tooling, local virus scanner updates, operating system patches, etc. The mention of 'unlikely' was in the context of broader best practices, not to discount your approach. To offer some insight into our approach, while we have CI, our team approaches the build/release scenario with local docker instances to provide repeatability across the team and isolation from our development environments; it's both fast and isolated/repeatable.

---

For now, if you update your webpack.config.ts configuration as should below, Console Ninja should not affect your build artefacts:

// webpack.config.ts

+ process.env.NODE_ENV = 'prod'
const configurationBuilder = () => {
  return {
    mode: "production",
    ...
  }
};

export default configurationBuilder;

[smcenlly]

This has been fixed in the latest version of Console Ninja (v1.0.317).