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

doc: add documentation for deprecation properties #16539

Closed
wants to merge 1 commit into from

Conversation

maclover7
Copy link
Contributor

Refs: #16394

Relevant commit history:

cc @vsemozhetbyt, I tried to avoid duplicating tons of documentation by linking out to other sections of the process docs, would love your thoughts :)

Checklist
Affected core subsystem(s)

doc

@nodejs-github-bot nodejs-github-bot added doc Issues and PRs related to the documentations. process Issues and PRs related to the process subsystem. labels Oct 26, 2017
@refack
Copy link
Contributor

refack commented Oct 27, 2017

Code LGTM, but the question is should they be documented or removed. AFAICT they were exposed as a rough mechanism of communicating the CLI flags to JS, they are not necessarily part of a succinct API.

Alternatively they (and other CLI flag mappings) could go behind a new process.cliArgs() API endpoint.


* {boolean}

The `process.throwDeprecation` property returns if the `--trace-deprecation`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A nit: --trace-deprecation -> --throw-deprecation

@@ -1667,6 +1680,32 @@ process.stdin.pipe(process.stdout);
*Note*: `process.stdout` differs from other Node.js streams in important ways,
see [note on process I/O][] for more information.

## process.traceDeprecation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems this should be placed after the process.title, ABC-wise.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my bad -- don't know why I thought a ### about IO was a ## 😞

@vsemozhetbyt
Copy link
Contributor

vsemozhetbyt commented Oct 27, 2017

I am not sure about some things.

  1. Can we say that the type is boolean if the value is undefined in case of the CLI key is not set?
console.log(
  process.noDeprecation, process.throwDeprecation, process.traceDeprecation
);
undefined undefined undefined
  1. Should we note that these properties are not just a mirrors of the CLI keys, but they can affect the warning behavior as per util.md notes.

  2. Should we duplicate the precedence note?

Let's see what other collaborators think.

@vsemozhetbyt
Copy link
Contributor

@refack It seems we cannot just remove them as they have been documented in util doc some years. We can deprecate them, but we may still need to document them for that in the proper place.

@vsemozhetbyt
Copy link
Contributor

BTW, thank you for the PR and digging into the history!

@addaleax
Copy link
Member

Alternatively they (and other CLI flag mappings) could go behind a new process.cliArgs() API endpoint.

Like process.execArgv? ;)

@refack
Copy link
Contributor

refack commented Oct 27, 2017

Alternatively they (and other CLI flag mappings) could go behind a new process.cliArgs() API endpoint.
Like process.execArgv? ;)

Hence my ambivalence about fully embracing those flags as 1st class API citizens 😕
Although process.execArgv still requires parsing and does not take into account NODE_OPTIONS

@BridgeAR
Copy link
Member

I personally think it would be best to deprecate these instead of documenting them. At the same time we can rephrase the util part where they are mentioned.

@maclover7
Copy link
Contributor Author

@BridgeAR Even if the props are deprecated publicly, they are still used within parts of Node core (like lib/internal/process/warning.js for example), so I'm not sold on what the maintenance benefit would be for doing that :(

@BridgeAR
Copy link
Member

BridgeAR commented Dec 7, 2017

@maclover7 even if we use some internally it does not mean users should always use those things as well. That is what internal is all about. At least that is how I see it. So it is not about a maintenance benefit but about being able to change internal details and or not overloading the user with information that does not improve anything.

@nylen
Copy link

nylen commented Dec 26, 2017

Please document and standardize these properties. I want to use process.throwDeprecation = true; in my code so that I don't have to start node with --throw-deprecation.

Edit: See also #17871


* {boolean}

The `process.noDeprecation` property returns if the `--no-deprecation`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly change "returns if" to "indicates whether or not"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would go with just "indicates whether", without the "or not".


* {boolean}

The `process.throwDeprecation` property returns if the `--throw-deprecation`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment here and below.

@maclover7
Copy link
Contributor Author

updated @cjihrig @apapirovski

@maclover7
Copy link
Contributor Author

ping @cjihrig @apapirovski would like to try and land this

Copy link
Contributor

@cjihrig cjihrig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes themselves look fine, but there were a few comments by others that brought up the alternative of deprecating and removing these properties.

@maclover7
Copy link
Contributor Author

@maclover7
Copy link
Contributor Author

Going to open a followup issue to discuss possible deprecation/removal of the properties.

@maclover7
Copy link
Contributor Author

c770f43

@maclover7 maclover7 closed this Jan 13, 2018
@maclover7 maclover7 deleted the jm-doc-process branch January 13, 2018 17:09
maclover7 added a commit that referenced this pull request Jan 13, 2018
PR-URL: #16539
Fixes: #16394
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
evanlucas pushed a commit that referenced this pull request Jan 30, 2018
PR-URL: #16539
Fixes: #16394
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit that referenced this pull request Feb 27, 2018
PR-URL: #16539
Fixes: #16394
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
MylesBorins pushed a commit that referenced this pull request Feb 27, 2018
PR-URL: #16539
Fixes: #16394
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This was referenced Feb 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
doc Issues and PRs related to the documentations. process Issues and PRs related to the process subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.