As an end-user, I don't want to ever see warnings or deprecations. However, when node is invoked from a shell script via a shebang, there is no opportunity to pass the --no-warnings
option to the process.
#!/usr/bin/env node --no-warnings
console.log("you will never get this far, so it doesn't matter if this compiles");
Is there an environment variable that can be set to toggle this option? If not, please add support for something like NODE_NO_WARNINGS=1
.
What's the solution?
When I try putting this at the top of my file:
#!/usr/bin/env NODE_NO_WARNINGS=1 node
I just get:
/usr/bin/env: ‘/path/to/my/script’: Text file busy
@mnpenner
like this:
#!/usr/bin/env
export NODE_NO_WARNINGS=1
it works. :)
@Doragd Huh? How would that work... the file contains JavaScript, it'll syntax error on export NODE_NO_WARNINGS=1
@mnpenner According to the link from @bnoordhuis, looks like it depends on the OS.
Does anyone have a cross-platform way to set the environment variable? Still haven't found any after researching and experimenting for a while. :(
@hexrcs env -S
- it's not standard but it works with BSD and GNU env(1).
@mnpenner
It really works for a shell script.
@Doragd We're talking about an executable .js file, not a .sh file which subsequently runs node.
I am now using a launcher script to spawn a child_process
to work around this limitation. Ugly, but fine for my purpose - it works with npm link
, global installs and whatnot.
#!/usr/bin/env node
const { spawnSync } = require("child_process");
const { resolve } = require("path");
// Say our original entrance script is `app.js`
const cmd = "node --no-warnings " + resolve(__dirname, "app.js");
spawnSync(cmd, { stdio: "inherit", shell: true });
If you only wanted to disable the warnings because you used the fs.promises
API as I did, I would recommend next time wrapping the original APIs in a promise manually, or sticking to util.promisify
, sync version of the APIs, instead of using this workaround.
Why is this closed? We really need a better way to disable warnings or at least to disable the Experimental API warning
You can just change your shebang to #! /usr/bin/env node --no-warnings
The --no-warnings
flag can be used with the NODE_OPTIONS
environment variable.
$ NODE_OPTIONS=--no-warnings ./node
@jasnell one issue I just noticed is that that can't be set from within the program when it has already launched.
@benjamingr, are you able to put it in the shebang? This worked for me:
#!/usr/bin/env NODE_OPTIONS=--no-warnings node
This also worked for me:
process.env.NODE_NO_WARNINGS = 1;
@squallstar doesn't work for me.
Which node version are you testing on? I'm testing fs.promises
on node 10.16.0. The module doesn't emit a warning in v12.13.0 though because I believe it's no longer experimental.
@hexrcs the above works for me on Node 12. I have right before a process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';
and this doesn't trigger a warning (while it does when NODE_NO_WARNINGS
is not defined).
Is this documented anywhere? I couldn't find anything about this env variable but it would certainly be great if we finally get this feature. :)
@hexrcs https://nodejs.org/api/cli.html#cli_node_no_warnings_1 (or search for NODE_NO_WARNINGS
on that page, the setting was added on Node 6).
Weird, because setting it to either a string "1"
or number 1
doesn't work on node v10 on my system (MacOS 10.14.6). (I was requiring the fs.promises
module.)
Just tested on node v12.13.0 using the example below, also doesn't seem to work. :(
$ node
> process.env.NODE_NO_WARNINGS = 1
// 1
> process.emitWarning('something strange happened')
// (node:18941) Warning: something strange happened
> process.env.NODE_NO_WARNINGS = "1"
// "1"
> process.emitWarning('something strange happened')
// (node:18941) Warning: something strange happened
If the node interpreter is spawned with node --no-warnings
, then process.emitWarning
will do nothing.
@hexrcs I just tested on Node v12.13.0 and I am using Mac OS 10.15.2 (19C57), works great from here.
@hexrcs something which you can try is to spawn a child process after the env variable has been updated. I remember doing that on previous versions of node when using commander to create a node-based CLI tool.
@squallstar Thanks for the tip :) I've been doing similar things:
https://github.com/nodejs/node/issues/10802#issuecomment-491560449
OK, I just upgraded node to v12.14.1, also doesn't work... Way too weird.
Anyway, I'll keep using the child process approach for now.
I raised this same issue here (oops): https://github.com/nodejs/node/issues/32876 and @sam-github kindly took the time to explain there's a solution using process.removeAllListeners('warning')
.
Most helpful comment
I raised this same issue here (oops): https://github.com/nodejs/node/issues/32876 and @sam-github kindly took the time to explain there's a solution using
process.removeAllListeners('warning')
.