Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

process: add allowedNodeEnvironmentFlags property #19335

Closed
wants to merge 3 commits into from

Conversation

@boneskull
Copy link
Contributor

@boneskull boneskull commented Mar 13, 2018

process.allowedNodeEnvironmentFlags lists all allowable flags within the NODE_OPTIONS environment variable.

UPDATE Aug 17 2018: I've modified this PR to provide a friendlier API, as described in this comment.


This change addresses #17740 as far as I need it to. The whitelist of NODE_OPTIONS-able flags (not counting v8 flags) correspond to the set of flags a CLI application may want to pass along to a spawned node process. Put another way, other Node.js-specific flags are essentially useless to CLI apps wrapping node.

  • I changed whitelist to be more obvious about what it's for, since it's no longer within a function.
  • I also changed whitelist to a vector to mimic the existing global static variables in node.cc (I didn't see a const char * [] anywhere; don't know if this matters)
  • Added a test
  • Added documentation
Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Copy link
Member

@bnoordhuis bnoordhuis left a comment

I see two issues with this PR:

  1. It doesn't address V8 flags, and
  2. The whitelist is only a subset of the flags.
src/node.cc Outdated
@@ -564,6 +564,47 @@ const char *signo_string(int signo) {
}
}

static std::vector<std::string> environment_flags = {

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 14, 2018
Member

std::vector is kinda wasteful for this. Can you change it back to const char*[]? Or better, const char* const [].

This comment has been minimized.

@boneskull

boneskull Mar 15, 2018
Author Contributor

will do

src/node.cc Outdated
@@ -3078,6 +3119,14 @@ void SetupProcessObject(Environment* env,
process->Set(FIXED_ONE_BYTE_STRING(env->isolate(), "execArgv"),
exec_arguments);

// process.envFlags
Local<Array> env_flags = Array::New(env->isolate());

This comment has been minimized.

@bnoordhuis

bnoordhuis Mar 14, 2018
Member

Preallocate the array by passing the size as the second argument.

This comment has been minimized.

@boneskull

boneskull Mar 15, 2018
Author Contributor

will do. I found another place where it wasn't preallocated (involving another vector, preload_modules, so this is why I removed it.

@gibfahn
Copy link
Member

@gibfahn gibfahn commented Mar 14, 2018

The whitelist of NODE_OPTIONS-able flags (not counting v8 flags) correspond to the set of flags a CLI application may want to pass along to a spawned node process. Put another way, other Node.js-specific flags are essentially useless to CLI apps wrapping node.

I'm not sure this is true. The original idea was for NODE_OPTIONS to be able to pass through any flags except a few that didn't make sense, but it was changed to a whitelist due to security concerns (#12028).

It seems quite likely to me that there are flags that cli apps like mocha might want to pass to node that are not in the NODE_OPTIONS whitelist.

EDIT: I'm not sure what the best solution to this is, but maybe it would be enough to just expose all of the command line flags, and then filter the ones you don't need in mocha.

@gibfahn
Copy link
Member

@gibfahn gibfahn commented Mar 14, 2018

It doesn't address V8 flags

What would be your preferred solution to this @bnoordhuis ? Presumably the best solution would be to add a similar option to V8 that returns a list of flags, and then expose those flags in a similar way. Things probably start to get complex though, we'd probably want process.flags.node, process.flags.v8, and maybe process.flags.both (not to mention maybe process.flags.nodeOptions for the NODE_OPTIONS whitelist).

I guess alternatively we could do what you suggested in #17740 (comment) and parse the output of d8 --help when building node or something?

Either way, as long as we allow for the option of adding V8 options in the future, I don't see why we'd need to add V8 options at the same time as node options.

Am I right in thinking that all V8 options start with --v8? If so then with this config variable you can easily work out whether a flag should be forwarded to node or not

@jasnell
Copy link
Member

@jasnell jasnell commented Mar 14, 2018

What's the use case for this?

@gibfahn
Copy link
Member

@gibfahn gibfahn commented Mar 14, 2018

What's the use case for this?

@jasnell that's covered in the linked issue (#17740).

@vkurchatkin
Copy link
Contributor

@vkurchatkin vkurchatkin commented Mar 14, 2018

-1. The justification seems pretty unconvincing.

@Trott
Copy link
Member

@Trott Trott commented Mar 14, 2018

-1. The justification seems pretty unconvincing.

@vkurchatkin Can you provide a little more detail? Is the use case invalid? Or is this something that doesn't need to be in core? Or...what's unconvincing?

@vkurchatkin
Copy link
Contributor

@vkurchatkin vkurchatkin commented Mar 14, 2018

@Trott In the issue @boneskull admits, that something like --node-flags= would solve the problem. That's something that I would do without a second thought.

Yes, I would say that the use case is invalid, in my opinion. Even if it wasn't, just one pretty specific use case doesn't warrant such an addition.

@gibfahn
Copy link
Member

@gibfahn gibfahn commented Mar 14, 2018

Okay, so thinking about this further (and talking to @boneskull), if the purpose of this option is to allow people who write cli apps to know which flags a user might want to pass through to node, then having the list of relevant flags match the list in NODE_OPTIONS might make sense. It depends whether there's a difference between the two lists.

doc/api/process.md Outdated
@@ -916,6 +916,63 @@ console.log(process.env.test);
// => 1
```

## process.envFlags
<!-- YAML
added: v10.0.0

This comment has been minimized.

@richardlau

richardlau Mar 14, 2018
Member

This should be added: REPLACEME. The releaser will substitute the actual version when making the release.

This comment has been minimized.

@boneskull

boneskull Mar 15, 2018
Author Contributor

I figured that wasn't right, but didn't know what to put. Is it documented somewhere?

This comment has been minimized.

@addaleax

addaleax Mar 15, 2018
Member

@boneskull Heh, yes. 😄 I introduced these things, and I agree that this should be documented somewhere, but there’s one question that has always stopped me from doing it myself until now:

Where would people look for such documentation?

This comment has been minimized.

@Trott

Trott Mar 15, 2018
Member

CONTRIBUTING.md perhaps?

This comment has been minimized.

@gibfahn

gibfahn Mar 16, 2018
Member

If we could catch this on landing (i.e. with nodejs/node-core-utils#193) then I think that would make a big difference, although documenting is a good idea too.

@jdalton jdalton mentioned this pull request Mar 15, 2018
2 of 3 tasks complete
@boneskull
Copy link
Contributor Author

@boneskull boneskull commented Mar 15, 2018

This would be useful for any CLI app which chooses to "pass through" Node.js options. It provides a better UX than having to execute a script via node <flags> /path/to/executable <more flags>. It's also easier to stomach for those users who are new to the command line. Likewise, it's a better UX than prefixing each with --node-.

If the above seems too particular or unnecessary, I hope reviewers can briefly put themselves in the shoes of maintainers, contributors, and consumers of userland CLI apps. In other words, please don't dismiss it just because it's not something which you often encounter or struggle with.


The reason this does not include "all" flags (v8 flags nor non-NODE_OPTIONS-flags) is threefold:

  1. CLI apps can match against /--v8-.+/ and pass those through. There's no such easy regex for matching Node.js flags.
  2. --version, --help and its ilk (flags not appearing in NODE_OPTIONS) are essentially useless, as they fundamentally change node's behavior to something other than "execute this script"
  3. It will add more complexity / overhead to gather the v8 flags, whether at compile or runtime

Then, I don't know of a use case (this does not imply there isn't one, of course) for "all" flags unless besides the human need to be completionist. Collect 'em all, etc. 😉

@ljharb
Copy link
Member

@ljharb ljharb commented Mar 15, 2018

One reason for "all" flags is, then I don't have to know to pass through v8 options - I just have this list as a single source of truth.

@boneskull
Copy link
Contributor Author

@boneskull boneskull commented Mar 15, 2018

@ljharb This is true.

Entertaining the idea further, if they were to be added:

If I were to parse d8 --help (or whatever node --v8-options calls) at build time, what would be the preferred way to pull that output in? Generate a text file and parse it? Generate a header file? #define a bunch of stuff?

If we do do that, it means we're parsing output intended to be human-readable. IMO, this isn't too terribly kind to the v8 team. The output will also vary by architecture.

Maybe better to read flag-definitions.h directly?

@boneskull boneskull force-pushed the boneskull:env-flags branch 2 times, most recently Mar 15, 2018
@jasnell
Copy link
Member

@jasnell jasnell commented Mar 16, 2018

I'd like to get @addaleax's take on this. I know she's been giving some thought to improved handling of the command line arguments here recently and may have some ideas on how to best proceed here.

@boneskull
Copy link
Contributor Author

@boneskull boneskull commented Mar 26, 2018

(a friendly nag at @addaleax)

@addaleax
Copy link
Member

@addaleax addaleax commented Mar 26, 2018

@boneskull Sorry, kinda missed the ping here. I don’t have strong opinions on this, and I don't think the kind of refactor I'm having in mind would necessarily change the API for this feature.

I would, however, appreciate a more expressive name than envFlags -- maybe something like process.allowedEnvironmentNodeFlags? It's verbose but it gets to the point of what this array means.

@boneskull
Copy link
Contributor Author

@boneskull boneskull commented Mar 27, 2018

I'll go ahead and change the name.

Can I please have some guidance as asked in this comment? I would like to see if I can pull the v8 flags in as well, but I'm unsure of how others would approach this.

@bnoordhuis
Copy link
Member

@bnoordhuis bnoordhuis commented Mar 27, 2018

Maybe better to read flag-definitions.h directly?

That won't work (reliably) for the following reasons:

  1. its implementation changes over time (maintenance hassle)
  2. its content changes based on V8's build flags, which are different from node's build flags
  3. it gives the wrong answers when linking against a shared library build of V8

A couple of solutions/workarounds:

  1. Petition V8 for an API that lets you query the flags at runtime.
  2. Two-stage build: parse output of node --v8-options and compile that into the stage 2 build
  3. Hack: redirect stderr with e.g. fmemopen() and call v8::V8::SetFlagsFromString("--help").

(2) and (3) are still prone to break when the format changes; (1) is arguably the best option.

@boneskull
Copy link
Contributor Author

@boneskull boneskull commented Mar 27, 2018

I'd rather not introduce (2) or (3) if it's prone to break, unless there are some guarantees from V8 that it won't. I'll follow up there.

@ljharb Does this sound reasonable?

  1. We exposed process.allowedEnvironmentNodeFlags (roughly as this PR is written)
  2. Petition V8 for runtime access to flags
  3. Add the V8 flags as e.g. process.allowedV8Flags when/if runtime access to V8 flags lands
@ljharb
Copy link
Member

@ljharb ljharb commented Mar 27, 2018

@boneskull seems like a good plan. Any chance they could be an object mapping arg names to provided values rather than just a list of allowed names?

@boneskull
Copy link
Contributor Author

@boneskull boneskull commented Mar 27, 2018

@ljharb That sounds like just cross-referencing with process.execArgv...?

@ljharb
Copy link
Member

@ljharb ljharb commented Mar 27, 2018

fair, it just seems like it’d be nice to avoid the extra step.

@boneskull boneskull changed the title process: add envFlags property process: add allowedEnvironmentNodeFlags property Apr 9, 2018
Copy link
Member

@bcoe bcoe left a comment

a few small changes requested, but in general I like this addition.

This solves a real use-case for command line tools like mocha, which need to ship arguments to multiple bins.

// --v8-options
// These flags are disallowed because security:
// --preserve-symlinks
const char* const environment_flags[] = {

This comment has been minimized.

@bcoe

bcoe Aug 20, 2018
Member

to fit with other constant naming conventions, should this be kEnvironmentFlags?

This comment has been minimized.

@boneskull

boneskull Aug 22, 2018
Author Contributor

That's a good question! 😄

This comment has been minimized.

@addaleax

addaleax Aug 23, 2018
Member

I don’t think we’ve use the kSomething notation for non-primitives in C++ so far. This can stay as-is, if you like (ditto below)

};

// V8 options (define with '_', which allows '-' or '_')
const char* const v8_environment_flags[] = {

This comment has been minimized.

@bcoe

bcoe Aug 20, 2018
Member

likewise, kV8EnvironmentFlags (unless another reviewer more familiar with the C++ codebase has said otherwise).

"--stack_trace_limit",
};

int v8_environment_flags_count = arraysize(v8_environment_flags);

This comment has been minimized.

@bcoe

bcoe Aug 20, 2018
Member

It seems like a bit of a micro-optimization to store this value, and it puts more variables in global space; I'd just use arraysize() in both places where this variable is used personally.

This comment has been minimized.

@boneskull

boneskull Aug 22, 2018
Author Contributor

I was having trouble getting my code to compile using arraysize() within node_config.cc. I'll dig up the error...

This comment has been minimized.

@addaleax

addaleax Aug 23, 2018
Member

That might be an issue of missing includes (node_internals.h?)

This comment has been minimized.

@boneskull

boneskull Aug 23, 2018
Author Contributor

Adding node_internals.h to node_config.cc results in:

../src/node_internals.h:239:18: note: candidate template ignored: could not match 'const T [N]' against 'const char *const []'

This comment has been minimized.

@boneskull

boneskull Aug 24, 2018
Author Contributor

After some chatter about this in IRC, we came to the conclusion that we don't know why arraysize isn't working in node_config.cc. I'm going to leave it as-is for now.

test/parallel/test-process-env-allowed-flags.js Outdated
assert.strictEqual(flag === 'foo', false);
});

process.allowedNodeEnvironmentFlags.clear();

This comment has been minimized.

@bcoe

bcoe Aug 20, 2018
Member

I've been getting in the habit of putting a comment above each test case lexically scoping the test, so that:

  1. it's less likely that test setup and teardown get clumped together.
  2. you have a description of what's being tested for.
// should return false if flag is not in allowedNodeEnvironmentFlags
{
  process.allowedNodeEnvironmentFlags.add('foo');
  assert.strictEqual(process.allowedNodeEnvironmentFlags.has('foo'), false);
  process.allowedNodeEnvironmentFlags.forEach((flag) => {
    assert.strictEqual(flag === 'foo', false);
  });
}

CC: @ratracegrad

This comment has been minimized.

@boneskull

boneskull Aug 23, 2018
Author Contributor

I've done some grouping in this manner

read-only `Set` of flags allowable within the [`NODE_OPTIONS`][]
environment variable.

`process.allowedNodeEnvironmentFlags` extends `Set`, but overrides

This comment has been minimized.

@bcoe

bcoe Aug 20, 2018
Member

I think this is an implementation detail that the person reading the docs doesn't really need to know, I'd just concentrate on describing the behavior of the api, e.g., how to use .has() to check for the flag.

This comment has been minimized.

@boneskull

boneskull Aug 22, 2018
Author Contributor

I thought this qualifier was necessary since the "type" of this API member is Set. Users expecting it to work exactly like a Set will be disappointed. Perhaps the "type" should just be something generic like "object" to avoid unwanted expectations?

This comment has been minimized.

@ljharb

ljharb Aug 22, 2018
Member

I think mentioning that it's a Set subclass is important, and is more than just an implementation detail - it's the observable interface.

@boneskull
Copy link
Contributor Author

@boneskull boneskull commented Aug 22, 2018

failure is tools/doc/type-parser.js doesn't recognize Set

"--stack_trace_limit",
};

int v8_environment_flags_count = arraysize(v8_environment_flags);

This comment has been minimized.

@addaleax

addaleax Aug 23, 2018
Member

That might be an issue of missing includes (node_internals.h?)

@boneskull boneskull force-pushed the boneskull:env-flags branch 2 times, most recently Aug 23, 2018
`process.allowedNodeEnvironmentFlags` provides an API to validate and list flags as specified in `NODE_OPTIONS` from user code.

Refs: #17740
Signed-off-by: Christopher Hiller <boneskull@boneskull.com>
@boneskull boneskull force-pushed the boneskull:env-flags branch to 7830f6e Aug 23, 2018
@boneskull
Copy link
Contributor Author

@boneskull boneskull commented Aug 24, 2018

@Trott It's not clear to me what needs to happen to get this merged. wait 72h?

I've addressed recent comments, and the lone rejection was withdrawn. It doesn't seem--for lack of a better word--fair to require every approver to re-approve this...

@ljharb
ljharb approved these changes Aug 24, 2018
Copy link
Member

@ljharb ljharb left a comment

<3 JS robustness LGTM

}

delete() {
// noop, `Set` API compatible

This comment has been minimized.

@ljharb

ljharb Aug 24, 2018
Member

you could also choose to throw here, which would be consistent with delete on a frozen object in strict mode.

This comment has been minimized.

@boneskull

boneskull Aug 24, 2018
Author Contributor

hmm, not a bad idea.

This comment has been minimized.

@boneskull

boneskull Aug 24, 2018
Author Contributor

I'm going to leave these as-is, I think

}

clear() {
// noop

This comment has been minimized.

@ljharb

ljharb Aug 24, 2018
Member

same here

@@ -18,7 +18,7 @@ const jsGlobalTypes = [
'Array', 'ArrayBuffer', 'DataView', 'Date', 'Error', 'EvalError', 'Function',
'Object', 'Promise', 'RangeError', 'ReferenceError', 'RegExp',
'SharedArrayBuffer', 'SyntaxError', 'TypeError', 'TypedArray', 'URIError',
'Uint8Array',
'Uint8Array', 'Set'

This comment has been minimized.

@ljharb

ljharb Aug 24, 2018
Member

should this just go ahead and add Map, WeakSet, WeakMap, Symbol, etc?

This comment has been minimized.

@vsemozhetbyt

vsemozhetbyt Aug 24, 2018
Contributor

@ljharb We had all common globals here but unused ones were purged in 6ac3c44

@boneskull Nit: These types are sorted alphabetically, so the Set should go after 'RegExp'.

This comment has been minimized.

@ljharb

ljharb Aug 24, 2018
Member

that seems like it serves only to frustrate contributors in the future when they use normal parts of the language :-/ cc @Trott

@Trott
Copy link
Member

@Trott Trott commented Aug 24, 2018

It doesn't seem--for lack of a better word--fair to require every approver to re-approve this...

It's not required. I was just suggesting that, given the changes, a few re-approvals would be good.

I think this is good to land if CI is green. I'll alphabetize that one entry in type-parser.js while landing. As far as @ljharb's comment that we should add Map etc., I don't dispute it, but that can certainly happen in another PR. (Maybe there's a good way to generate them dynamically rather than having them hard-coded. But again, outside the scope of this PR for sure.)

Trott added 2 commits Aug 24, 2018
Trott added a commit to Trott/io.js that referenced this pull request Aug 25, 2018
`process.allowedNodeEnvironmentFlags` provides an API to validate and
list flags as specified in `NODE_OPTIONS` from user code.

Refs: nodejs#17740
Signed-off-by: Christopher Hiller <boneskull@boneskull.com>

PR-URL: nodejs#19335
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Sam Ruby <rubys@intertwingly.net>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
@Trott
Copy link
Member

@Trott Trott commented Aug 25, 2018

Landed in 80143f6.

@Trott Trott closed this Aug 25, 2018
addaleax added a commit that referenced this pull request Aug 28, 2018
`process.allowedNodeEnvironmentFlags` provides an API to validate and
list flags as specified in `NODE_OPTIONS` from user code.

Refs: #17740
Signed-off-by: Christopher Hiller <boneskull@boneskull.com>

PR-URL: #19335
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Sam Ruby <rubys@intertwingly.net>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
targos added a commit that referenced this pull request Sep 3, 2018
`process.allowedNodeEnvironmentFlags` provides an API to validate and
list flags as specified in `NODE_OPTIONS` from user code.

Refs: #17740
Signed-off-by: Christopher Hiller <boneskull@boneskull.com>

PR-URL: #19335
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Sam Ruby <rubys@intertwingly.net>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
targos added a commit that referenced this pull request Sep 5, 2018
Notable changes:

* child_process:
  * `TypedArray` and `DataView` values are now accepted as input by
    `execFileSync` and `spawnSync`. #22409
* coverage:
  * Native V8 code coverage information can now be output to disk by setting the
    environment variable `NODE_V8_COVERAGE` to a directory. #22527
* deps:
  * The bundled npm was upgraded to version 6.4.1. #22591
    * Changelogs:
      [6.3.0-next.0](https://github.com/npm/cli/releases/tag/v6.3.0-next.0)
      [6.3.0](https://github.com/npm/cli/releases/tag/v6.3.0)
      [6.4.0](https://github.com/npm/cli/releases/tag/v6.4.0)
      [6.4.1](https://github.com/npm/cli/releases/tag/v6.4.1)
* fs:
  * The methods `fs.read`, `fs.readSync`, `fs.write`, `fs.writeSync`,
    `fs.writeFile` and `fs.writeFileSync` now all accept `TypedArray` and
    `DataView` objects. #22150
  * A new boolean option, `withFileTypes`, can be passed to to `fs.readdir` and
    `fs.readdirSync`. If set to true, the methods return an array of directory
    entries. These are objects that can be used to determine the type of each
    entry and filter them based on that without calling `fs.stat`. #22020
* http2:
  * The `http2` module is no longer experimental. #22466
* os:
  * Added two new methods: `os.getPriority` and `os.setPriority`, allowing to
    manipulate the scheduling priority of processes. #22394
* process:
  * Added `process.allowedNodeEnvironmentFlags`. This object can be used to
    programmatically validate and list flags that are allowed in the
    `NODE_OPTIONS` environment variable. #19335
* src:
  * Deprecated option variables in public C++ API. #22392
  * Refactored options parsing. #22392
* vm:
  * Added `vm.compileFunction`, a method to create new JavaScript functions from
    a source body, with options similar to those of the other `vm` methods. #21571
* Added new collaborators:
  * [lundibundi](https://github.com/lundibundi) - Denys Otrishko

PR-URL: #22716
targos added a commit that referenced this pull request Sep 6, 2018
`process.allowedNodeEnvironmentFlags` provides an API to validate and
list flags as specified in `NODE_OPTIONS` from user code.

Refs: #17740
Signed-off-by: Christopher Hiller <boneskull@boneskull.com>

PR-URL: #19335
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Sam Ruby <rubys@intertwingly.net>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
targos added a commit that referenced this pull request Sep 6, 2018
Notable changes:

* child_process:
  * `TypedArray` and `DataView` values are now accepted as input by
    `execFileSync` and `spawnSync`. #22409
* coverage:
  * Native V8 code coverage information can now be output to disk by setting the
    environment variable `NODE_V8_COVERAGE` to a directory. #22527
* deps:
  * The bundled npm was upgraded to version 6.4.1. #22591
    * Changelogs:
      [6.3.0-next.0](https://github.com/npm/cli/releases/tag/v6.3.0-next.0)
      [6.3.0](https://github.com/npm/cli/releases/tag/v6.3.0)
      [6.4.0](https://github.com/npm/cli/releases/tag/v6.4.0)
      [6.4.1](https://github.com/npm/cli/releases/tag/v6.4.1)
* fs:
  * The methods `fs.read`, `fs.readSync`, `fs.write`, `fs.writeSync`,
    `fs.writeFile` and `fs.writeFileSync` now all accept `TypedArray` and
    `DataView` objects. #22150
  * A new boolean option, `withFileTypes`, can be passed to to `fs.readdir` and
    `fs.readdirSync`. If set to true, the methods return an array of directory
    entries. These are objects that can be used to determine the type of each
    entry and filter them based on that without calling `fs.stat`. #22020
* http2:
  * The `http2` module is no longer experimental. #22466
* os:
  * Added two new methods: `os.getPriority` and `os.setPriority`, allowing to
    manipulate the scheduling priority of processes. #22407
* process:
  * Added `process.allowedNodeEnvironmentFlags`. This object can be used to
    programmatically validate and list flags that are allowed in the
    `NODE_OPTIONS` environment variable. #19335
* src:
  * Deprecated option variables in public C++ API. #22515
  * Refactored options parsing. #22392
* vm:
  * Added `vm.compileFunction`, a method to create new JavaScript functions from
    a source body, with options similar to those of the other `vm` methods. #21571
* Added new collaborators:
  * [lundibundi](https://github.com/lundibundi) - Denys Otrishko

PR-URL: #22716
targos added a commit that referenced this pull request Sep 6, 2018
Notable changes:

* child_process:
  * `TypedArray` and `DataView` values are now accepted as input by
    `execFileSync` and `spawnSync`. #22409
* coverage:
  * Native V8 code coverage information can now be output to disk by setting the
    environment variable `NODE_V8_COVERAGE` to a directory. #22527
* deps:
  * The bundled npm was upgraded to version 6.4.1. #22591
    * Changelogs:
      [6.3.0-next.0](https://github.com/npm/cli/releases/tag/v6.3.0-next.0)
      [6.3.0](https://github.com/npm/cli/releases/tag/v6.3.0)
      [6.4.0](https://github.com/npm/cli/releases/tag/v6.4.0)
      [6.4.1](https://github.com/npm/cli/releases/tag/v6.4.1)
* fs:
  * The methods `fs.read`, `fs.readSync`, `fs.write`, `fs.writeSync`,
    `fs.writeFile` and `fs.writeFileSync` now all accept `TypedArray` and
    `DataView` objects. #22150
  * A new boolean option, `withFileTypes`, can be passed to to `fs.readdir` and
    `fs.readdirSync`. If set to true, the methods return an array of directory
    entries. These are objects that can be used to determine the type of each
    entry and filter them based on that without calling `fs.stat`. #22020
* http2:
  * The `http2` module is no longer experimental. #22466
* os:
  * Added two new methods: `os.getPriority` and `os.setPriority`, allowing to
    manipulate the scheduling priority of processes. #22407
* process:
  * Added `process.allowedNodeEnvironmentFlags`. This object can be used to
    programmatically validate and list flags that are allowed in the
    `NODE_OPTIONS` environment variable. #19335
* src:
  * Deprecated option variables in public C++ API. #22515
  * Refactored options parsing. #22392
* vm:
  * Added `vm.compileFunction`, a method to create new JavaScript functions from
    a source body, with options similar to those of the other `vm` methods. #21571
* Added new collaborators:
  * [lundibundi](https://github.com/lundibundi) - Denys Otrishko

PR-URL: #22716
targos added a commit that referenced this pull request Sep 6, 2018
Notable changes:

* child_process:
  * `TypedArray` and `DataView` values are now accepted as input by
    `execFileSync` and `spawnSync`. #22409
* coverage:
  * Native V8 code coverage information can now be output to disk by setting the
    environment variable `NODE_V8_COVERAGE` to a directory. #22527
* deps:
  * The bundled npm was upgraded to version 6.4.1. #22591
    * Changelogs:
      [6.3.0-next.0](https://github.com/npm/cli/releases/tag/v6.3.0-next.0)
      [6.3.0](https://github.com/npm/cli/releases/tag/v6.3.0)
      [6.4.0](https://github.com/npm/cli/releases/tag/v6.4.0)
      [6.4.1](https://github.com/npm/cli/releases/tag/v6.4.1)
* fs:
  * The methods `fs.read`, `fs.readSync`, `fs.write`, `fs.writeSync`,
    `fs.writeFile` and `fs.writeFileSync` now all accept `TypedArray` and
    `DataView` objects. #22150
  * A new boolean option, `withFileTypes`, can be passed to to `fs.readdir` and
    `fs.readdirSync`. If set to true, the methods return an array of directory
    entries. These are objects that can be used to determine the type of each
    entry and filter them based on that without calling `fs.stat`. #22020
* http2:
  * The `http2` module is no longer experimental. #22466
* os:
  * Added two new methods: `os.getPriority` and `os.setPriority`, allowing to
    manipulate the scheduling priority of processes. #22407
* process:
  * Added `process.allowedNodeEnvironmentFlags`. This object can be used to
    programmatically validate and list flags that are allowed in the
    `NODE_OPTIONS` environment variable. #19335
* src:
  * Deprecated option variables in public C++ API. #22515
  * Refactored options parsing. #22392
* vm:
  * Added `vm.compileFunction`, a method to create new JavaScript functions from
    a source body, with options similar to those of the other `vm` methods. #21571
* Added new collaborators:
  * [lundibundi](https://github.com/lundibundi) - Denys Otrishko

PR-URL: #22716
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.