sindresorhus / strip-debug Goto Github PK
View Code? Open in Web Editor NEWStrip console, alert, and debugger statements from JavaScript code
License: MIT License
Strip console, alert, and debugger statements from JavaScript code
License: MIT License
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.
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!
to allow for console.warn and console.error to remain for instance
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!
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
.
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?
stripDebug({
alert:true,
debugger:false,
console:true
})
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');
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?
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());
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.
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.
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.
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.
From sindresorhus/gulp-strip-debug#10.
Blocked by millermedeiros/rocambole#29.
Might be better to just rewrite it as a Babel plugin.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.