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
base: master
from

Conversation

@boneskull
Contributor

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
@bnoordhuis

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.
Show outdated Hide outdated src/node.cc
Show outdated Hide outdated src/node.cc
@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Mar 14, 2018

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Mar 14, 2018

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 14, 2018

Member

What's the use case for this?

Member

jasnell commented Mar 14, 2018

What's the use case for this?

@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Mar 14, 2018

Member

What's the use case for this?

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

Member

gibfahn commented Mar 14, 2018

What's the use case for this?

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

@vkurchatkin

This comment has been minimized.

Show comment
Hide comment
@vkurchatkin

vkurchatkin Mar 14, 2018

Member

-1. The justification seems pretty unconvincing.

Member

vkurchatkin commented Mar 14, 2018

-1. The justification seems pretty unconvincing.

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Mar 14, 2018

Member

-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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@vkurchatkin

vkurchatkin Mar 14, 2018

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Mar 14, 2018

Member

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.

Member

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.

@jdalton jdalton referenced this pull request Mar 15, 2018

Closed

module: add builtinModules #16386

2 of 3 tasks complete
@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Mar 15, 2018

Contributor

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. 😉

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb 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.

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

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Mar 15, 2018

Contributor

@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?

Contributor

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?

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Mar 16, 2018

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Mar 26, 2018

Contributor

(a friendly nag at @addaleax)

Contributor

boneskull commented Mar 26, 2018

(a friendly nag at @addaleax)

@addaleax

This comment has been minimized.

Show comment
Hide comment
@addaleax

addaleax Mar 26, 2018

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Mar 27, 2018

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Mar 27, 2018

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Mar 27, 2018

Contributor

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
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb 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?

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

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Mar 27, 2018

Contributor

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

Contributor

boneskull commented Mar 27, 2018

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

@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Mar 27, 2018

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

ljharb commented Mar 27, 2018

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

@boneskull boneskull changed the title from process: add envFlags property to process: add allowedEnvironmentNodeFlags property Apr 9, 2018

@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Apr 9, 2018

Contributor

I've made some modifications:

  • renaming of property to allowedEnvironmentNodeFlags (cc @addaleax)
  • cross-reference list of flags with NODE_OPTIONS to ensure I wasn't missing anything (cc @gibfahn)
  • wrote a list of explicitly excluded flags and justification

Insofar as petitioning V8 (as suggested by @bnoordhuis), I had hoped it would be obvious how to do such a thing, but I was mistaken. How should I do this? Mailing list? Bug tracker? Any other suggestions on how to frame the request?

Contributor

boneskull commented Apr 9, 2018

I've made some modifications:

  • renaming of property to allowedEnvironmentNodeFlags (cc @addaleax)
  • cross-reference list of flags with NODE_OPTIONS to ensure I wasn't missing anything (cc @gibfahn)
  • wrote a list of explicitly excluded flags and justification

Insofar as petitioning V8 (as suggested by @bnoordhuis), I had hoped it would be obvious how to do such a thing, but I was mistaken. How should I do this? Mailing list? Bug tracker? Any other suggestions on how to frame the request?

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott
Member

Trott commented Apr 9, 2018

@addaleax addaleax referenced this pull request Aug 18, 2018

Closed

src: refactor options parsing #22392

2 of 2 tasks complete
@mcollina

LGTM

@rubys

rubys approved these changes Aug 19, 2018

I think I originally thought it was was all CLI flags, and not NODE_OPTIONS.

@bcoe

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?

@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

Contributor

That's a good question! 😄

@boneskull

boneskull Aug 22, 2018

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)

@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).

@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.

@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

Contributor

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

@boneskull

boneskull Aug 22, 2018

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?)

@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

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 []'
@boneskull

boneskull Aug 23, 2018

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

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.

@boneskull

boneskull Aug 24, 2018

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.

Show outdated Hide outdated test/parallel/test-process-env-allowed-flags.js
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.

@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

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?

@boneskull

boneskull Aug 22, 2018

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

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

@ljharb

ljharb Aug 22, 2018

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

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Aug 22, 2018

Contributor

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

Contributor

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?)

@addaleax

addaleax Aug 23, 2018

Member

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

process: add allowedNodeEnvironmentFlags property
`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

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Aug 24, 2018

Contributor

@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...

Contributor

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

<3 JS robustness LGTM

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

This comment has been minimized.

@ljharb

ljharb Aug 24, 2018

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

@ljharb

ljharb Aug 24, 2018

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

Contributor

hmm, not a bad idea.

@boneskull

boneskull Aug 24, 2018

Contributor

hmm, not a bad idea.

This comment has been minimized.

@boneskull

boneskull Aug 24, 2018

Contributor

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

@boneskull

boneskull Aug 24, 2018

Contributor

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

}
clear() {
// noop

This comment has been minimized.

@ljharb

ljharb Aug 24, 2018

same here

@ljharb
Show outdated Hide outdated tools/doc/type-parser.js
@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Aug 24, 2018

Member

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.)

Member

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 some commits Aug 24, 2018

@Trott

This comment has been minimized.

Show comment
Hide comment

Trott added a commit to Trott/io.js that referenced this pull request Aug 25, 2018

process: add allowedNodeEnvironmentFlags property
`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

This comment has been minimized.

Show comment
Hide comment
@Trott

Trott Aug 25, 2018

Member

Landed in 80143f6.

Member

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: add allowedNodeEnvironmentFlags property
`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: add allowedNodeEnvironmentFlags property
`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

2018-09-06, Version 10.10.0 (Current)
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

targos added a commit that referenced this pull request Sep 5, 2018

2018-09-06, Version 10.10.0 (Current)
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: https://github.com/nodejs/node/pull/22716

@targos targos referenced this pull request Sep 5, 2018

Merged

Release proposal: v10.10.0 #22716

targos added a commit that referenced this pull request Sep 6, 2018

process: add allowedNodeEnvironmentFlags property
`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

2018-09-06, Version 10.10.0 (Current)
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

2018-09-06, Version 10.10.0 (Current)
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

2018-09-06, Version 10.10.0 (Current)
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