sindresorhus / strip-debug

Strip console, alert, and debugger statements from JavaScript code

strip-debug

Strip console, alert, and debugger statements from JavaScript code

Useful for making sure you didn't leave any logging in production code.

Usage

npm install @babel/core strip-debug

Usage

import {transformSync} from '@babel/core';
import stripDebug from 'strip-debug';

transformSync('function foo(){console.log("foo");alert("foo");debugger;}', {
	plugins: [stripDebug]
}).code;
//=> 'function foo() { void 0;void 0; }'

To prevent any side-effects, console.*/alert* is replaced with void 0 instead of being stripped.

If you shadow the console global with your own local variable, it will still be removed.

Related

• strip-debug-cli - API for this module

strip-debug's Issues

Is there a way to preserve alerts?

I have a React component that calls alert("Some info message") inside a function. The function is called as a onClick event handler. Because there is no way to set an inline attribute onclick="alert('Some info message')" in React, I have to do it this way:

var FooComponent= React.createClass({
    onOptionSelect: function(e) {
        e.preventDefault();
        alert('Some info message.');
        return;
    },

So I want to preserve alert()s. How to achieve it?

If there a way to keep console.error?

Source Map support

From sindresorhus/gulp-strip-debug#10.

Blocked by millermedeiros/rocambole#29.

Might be better to just rewrite it as a Babel plugin.

Doesn't work with import/exports

Esprima fails to parse such files. sourceType: true needs to be passed to Esprima to fix this, but there is not way to pass options to Esprima.

Upgrade to rocambole 0.3.6

I'm trying to use strip-debug (via gulp-strip-debug) and am getting this error:

events.js:72
        throw er; // Unhandled 'error' event
              ^
TypeError: Cannot set property 'parent' of null
    at instrumentNodes (/Users/kevin/Workspace/sling-web/node_modules/gulp-strip-debug/node_modules/strip-debug/node_modules/rocambole/rocambole.js:69:21)
    at recursiveWalk (/Users/kevin/Workspace/sling-web/node_modules/gulp-strip-debug/node_modules/strip-debug/node_modules/rocambole/rocambole.js:339:10)
    at recursiveWalk (/Users/kevin/Workspace/sling-web/node_modules/gulp-strip-debug/node_modules/strip-debug/node_modules/rocambole/rocambole.js:364:17)
    at recursiveWalk (/Users/kevin/Workspace/sling-web/node_modules/gulp-strip-debug/node_modules/strip-debug/node_modules/rocambole/rocambole.js:360:13)
    at recursiveWalk (/Users/kevin/Workspace/sling-web/node_modules/gulp-strip-debug/node_modules/strip-debug/node_modules/rocambole/rocambole.js:360:13)
    at recursiveWalk (/Users/kevin/Workspace/sling-web/node_modules/gulp-strip-debug/node_modules/strip-debug/node_modules/rocambole/rocambole.js:360:13)
    at recursiveWalk (/Users/kevin/Workspace/sling-web/node_modules/gulp-strip-debug/node_modules/strip-debug/node_modules/rocambole/rocambole.js:364:17)
    at recursiveWalk (/Users/kevin/Workspace/sling-web/node_modules/gulp-strip-debug/node_modules/strip-debug/node_modules/rocambole/rocambole.js:364:17)
    at recursiveWalk (/Users/kevin/Workspace/sling-web/node_modules/gulp-strip-debug/node_modules/strip-debug/node_modules/rocambole/rocambole.js:360:13)
    at recursiveWalk (/Users/kevin/Workspace/sling-web/node_modules/gulp-strip-debug/node_modules/strip-debug/node_modules/rocambole/rocambole.js:364:17)

When I downgrade to gulp-strip-debug 0.1.1 (which uses strip-debug 0.1.0 and rocambole 0.3.6) the error is gone and everything works. As soon as I upgrade to gulp-strip-debug 0.2.0 (which uses strip-debug 0.2.0 and rocambole 0.3.1) I get this error.

The latest gulp-strip-debug, 1.0.1, uses strip-debug 1.0.0 and rocambole 0.3.1, which results in the same error. So, it seems that rocambole 0.3.6 is the correct version to use.

Looking at package.json it used to depend on ~0.3.1 but that's now changed to ^0.3.1. Please see https://www.npmjs.org/doc/misc/semver.html: "0.x.x versions are special: since the semver spec specifies that 0.x.x versions make no stability guarantees, only the version specified is considered valid."

So either change this to ~0.3.6 or 0.3.x or 0.3.

Errors

I was testing the module and I have many error, likely es6 / es7 problems with things like async, await, =>. Is this normal and a fix is possible?

export config

stripDebug({
alert:true,
debugger:false,
console:true
})

Ignore / Except specific lines

Nice, but how about an ability to ignore a specific line using a comment?
For example:

// strip-debug ignore-next-line
console.log('I am in production');

Add options?

It'd be great if you could pass options to strip-debug. In my use case I need the alert() call to remain in the production code.

e.g: stripDebug(['console','debugger']) would leave the alerts in place.

Failed to handle local variable named `console`

Input:

; (function () {
  const console = jQuery('.my-console');
  ace.edit(console.get(0));
}());

Output:

; (function () {
  const console = jQuery('.my-console');
  ace.edit(void 0);
}());

Expected:
No change from input.

This behavior should be documented clearly if it is the expected behavior.

request: log-level option

to allow for console.warn and console.error to remain for instance

Convert to Babel plugin

Rocambole, which this project is built on, is no longer maintained.

Would be best to convert this project to a Babel plugin. Then we also get #11 for free.

---

IssueHunt Summary

notwoods has been rewarded.

Backers (Total: $80.00)

• issuehunt ($80.00)

Submitted pull Requests

• #21 Attempt to convert to babel plugin
• #24 Convert to Babel plugin and add TypeScript types

---

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

Options request

Hi there!
Would be great to pass some options, like
{ logging: true, // remove console.log alerts: false // don't remove console.log }

in order to avoid removing alerts, since some apps are still using alerts as legit dialogs for their users :)

Thanks!

Handle edge cases

The following:

if (foo) console.log('hey')
nextLine();

is currently handled badly and results in:

if (foo) nextLine();

Not sure about this one though:

foo && console.log('bar');

which results in:

;

@jsoverson see any downsides of doing the above?

@jsoverson suggested I just replace the console.fn argument with 0. Though i would prefer to actually remove it if not too hard or fragile.

Problems when reading input from stdin

Hi!

I have a problem when piping the output from uglify into strip-debug. It works fine if I make it read from the file generated by uglify though. It throws this error.

The error points to a function called getStdin at cli.js. It looks like this.

It looked weird since it wasn't reading the data argument. If you call strip with the data argument instead of input it works fine. I'm just not sure if having input is necessary in there for other things to work.

If it's the only necessary change I could make a pr.

Thanks!

FATAL ERROR: JS Allocation failed - process out of memory

I recently cleaned my node_modules directory and re-ran npm install and started getting an out of memory error that I have traced back to this plugin (and its dependencies).

Take a look at the following simplified example that can reproduce this:

var stripDebug = require('strip-debug');
stripDebug('var obj = null; try { obj = "something"; } catch (e) { console.warn("NOPE!"); }').toString();

Version 1.0.1 processes this correctly, but the latest version 1.1.0 eats up tons of memory and eventually spits out an error: FATAL ERROR: JS Allocation failed - process out of memory

It appears that since the last time I cleared my node_modules directory and re-installed npm packages, some of the dependent packages have changed versions. The one that appears to impact this is the esprima package that is included through the strip-debug -> rocambole -> esprima dependency path. Currently npm provides [email protected]. If I manually downgrade that to 1.2.5 the above code works fine. If I run the above example file through the esprima online validator, it validates ok. So, I don't think the issue is with esprima directly. It is probably something higher up the chain is expecting something different than esprima now provides.

I have no good way of locking in the version of esprima or even this library. I am using this through your gulp-strip-debug library that uses ^1.0.0 (i.e. the latest 1.x.x or currently 1.1.0) instead of ~1.0.0 (i.e. 1.0.x or currently 1.0.1). Because 1.1.0 of this library introduced a breaking change, the gulp-strip-debug should probably be more explicit about which version it pulls in.

New edge case found

Hi there!

I was trying to give a go today to the grunt version of this script and I ran across an edge case. Which I really don't know why it's happening:

This is a test:

var test = {
    getReadSections: function(){
        var readSections = window.localStorage.getItem('storyReadSections') || '[]';
        return JSON.parse(readSections);
    }
};

Is stripped to:

var test = {getReadSections: function(){var readSections = ;return JSON.parse(readSections);}};

Giving you a bad code result and will fail upon execution.

I don't see any potential debugging sentence there. Here is the full code anyway I used to test this failure:

var stripDebug = require('strip-debug');


console.log(stripDebug(
        "var test = {" +
        "getReadSections: function(){" +
            "var readSections = window.localStorage.getItem('storyReadSections') || '[]';" +
            "return JSON.parse(readSections);"+
        "}};").toString());