-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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: deprecate vm.runInDebugContext #12243
Conversation
doc/api/deprecations.md
Outdated
@@ -582,6 +582,16 @@ deprecated. | |||
*Note*: `OutgoingMessage.prototype._renderHeaders` was never documented as | |||
an officially supported API. | |||
|
|||
<a id="DEP0068"></a> | |||
### DEP0064: vm.runInDebugContext(string) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, need to update string to DEP0068 or whatever the final number is.
doc/api/deprecations.md
Outdated
@@ -582,6 +582,16 @@ deprecated. | |||
*Note*: `OutgoingMessage.prototype._renderHeaders` was never documented as | |||
an officially supported API. | |||
|
|||
<a id="DEP0068"></a> | |||
### DEP0064: vm.runInDebugContext(string) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't these match?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed :) fixed.
FYI, https://github.com/strongloop/strong-agent/blob/7c3109b140678b98bda19ff914d9937c886e21e3/lib/dyninst.js#L19-L27, @ofrobots I think it was added because it can be useful, and had that specific use of accessing |
If its going to break, I'm +1 for deprecating in 8.x, to give people a chance to work around the upcoming disappearance. |
573f9d7
to
51a0031
Compare
If this is dependent in any way on the V8 debugger, then it absolutely would need to be pulled in 8.0.0 since the debugger is going to be pulled. |
Regarding the DEP00NN number, we should actually get some tooling in to handle these like the REPLACEME tags. The number should be assigned either when the PR lands or when the release is cut. |
This is not dependent on the JSON Debug Protocol ( @sam-github Speaking of migration, the idea is that V8-inspector can be used for in process debugging. The first step in enabling this is #11431. We are planning on a few follow-on PRs that will make the inspector available to userspace to allow functionality equivalent to what the Debug context is used for today. |
@TimothyGu Indeed. However It is hard to do that before 8.x because we need some semver major changes to land before the alternative API is possible. I do think you have a valid point however, it is not nice to deprecate an API before the alternative is really possible. This would leave us with NOT deprecating this at 8.0 which would give us less than 2 major cycles before it gets removed in 10.x. |
@ofrobots To be clear I'm not against this PR, since whether we warn or not the API is going to be removed from V8 very very soon. What concerns me more is the fact that none of our publicly-exposed functions should be printing a deprecation warning. Well, except for that deprecated function itself. For example, until modern V8 APIs that support what we need are in, I'm fine with a function accessible only internally that does not print a deprecation warning, and an externally accessible function that does. |
Good point, we cannot have core generate deprecation notices from it's own use of APIs. That's just bad form. Having an |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Blocking this before #12243 (comment) is resolved.
PR for JavaScript bindings for the inspector is now open: #12263. |
Would it be reasonable to wrap |
@joshgav That'd work for me. |
51a0031
to
c1f6282
Compare
@TimothyGu done, PTAL. |
Sorry to join in late, can I ask what will be the alternative? |
@ofrobots any suggestions? We could not deprecate it... but then it will simply disappear without a full deprecation cycle, and v8 doesn't have an alternative yet if I understood the comments correctly, so we seem to be stuck between a rock and a hard place. |
doc/api/deprecations.md
Outdated
Type: Runtime | ||
|
||
The DebugContext is being removed from V8 5.8+ along with the legacy debugger | ||
interface. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible to mention when v8 5.8 is expected to land? Most people don't know what version of v8 is in specific node versions, so I suggest adding something like "Deprecated to warn users that this function will have to be deleted when Node.js next updates V8." (or something of the like).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually not accurate. The Debug context is slated to go away at the end of the year which would probably be either M63 or M64. It might be better to state the Node version (10.0) that this is expected to land in.
The legacy debugger interface is gone in V8 5.8.
It seems that the API was experimental and it is not clear if the 2-major deprecation policy applies to V8 APIs anyway. IMO we should allow something like #12263 to happen and add the deprecation message around the time 8.x goes LTS. This will give allow the ecosystem to migrate. Perhaps this can be one of the new 'pending deprecations' for now? |
@ofrobots We skip the 2-major rule when forced to by external deps, but you anticipate this API going away in 10.x? If its going to disappear in node 10.x, then we could docs-only deprecate in 8.x, and runtime deprecate in 9.x, and outright delete in 10.x, which is as smooth as any deprecation cycle can be. |
Good point. I agree that this should be a doc-only deprecation in At the CTC-V8 meeting in February, the V8 team indicated that debug context will be removed by EOY, which lines up with Node 10.x. |
@ofrobots @sam-github okay will update to docs-only deprecation, mention 10.x instead of a V8 version, and include @addaleax's suggestions above.
Is #12263 a sufficient alternative? |
That's the hope. I think all the ecosystem uses can be addressed by it, but it is a sufficiently different API and mechanism. It would be good to offer this as an experimental API and get feedback from the ecosystem on whether it addresses all the use-cases. |
this needs a rebase :-) |
c1f6282
to
a7fcb0a
Compare
Split runtime deprecation into #12815 to land on 9.x. Updated this PR to only be a docs deprecation. |
Docs-only deprecation for v8.0.0. Runtime deprecation planned for v9.0.0. Removal planned for v10.0.0. PR-URL: nodejs#12243 Reviewed-By: _tbd_ Reviewed-By: _tbd_
a7fcb0a
to
7271988
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, looks good to me. It’s a bit unfortunate we have to go with just “An alternative is in development” but I guess that’s just the truth… ¯_(ツ)_/¯
Landed in eb535c5. Thanks! |
Docs-only deprecation for v8.0.0. Runtime deprecation planned for v9.0.0. Removal planned for v10.0.0. PR-URL: #12243 Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>
Docs-only deprecation for v8.0.0. Runtime deprecation planned for v9.0.0. Removal planned for v10.0.0. PR-URL: nodejs#12243 Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
src, debugger
Per https://github.com/nodejs/diagnostics/blob/master/wg-meetings/2017-03-23.md#3-deprecate-vmrunindebugcontext-api:
@jasnell should this be included in 8.0.0? Sorry it's late...
cc @ofrobots @eugeneo