You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
should the fact that this is bound to module.exports be documented? #9623
@mscdex Should it be documented for the difference between strict mode and normal? or documented for prohibiting using this to export. Cause of there is some one use this to export previously.
I don't like to encourage its use, but on the other hand, it is used, and if you use it by accident, and then want to understand why your code worked the way it does, its nice to find docs that explain that.
Put another way: if we hate this so much we don't want to document it... can we just remove it?
I suspect it will break the world if removed... in which case, we won't remove it, so why not describe it, and also describe how it makes your code node-specific?
It should be documented so that if anybody finds code doing it, they can understand what is happening. It should also be doced as deprecated.
Any chance we can remove the feature, or is it harmless to leave in indefinitely? Will a future v8 update be likely to remove the feature for node? Would docs-deprecation be the first step to runtime deprecation?
Any chance we can remove the feature, or is it harmless to leave in indefinitely?
Even though I've never seen this actually used, nor do I encourage it, my fear is that people might be actually using this. And since we don't actually have a need to deprecate this, I'd support maintaining the status quo.
Will a future v8 update be likely to remove the feature for node?
The this behavior is entirely implemented in JS and doesn't depend on any V8 specifics:
Note: the upcoming ES module implementation has this === undefined per spec, and since it's a completely different execution mode it doesn't change the behavior discussed here.
@niveditn deprecations go into the deprecations.md. I think it would be best if you just open a PR as soon as you personally have the feeling it is usable. If there are further improvements necessary they can be done in the open PR.
Activity
iamchenxin commentedon Nov 15, 2016
test with
"babel-plugin-transform-es2015-modules-commonjs": "^6.18.0"thisis set toundefined.iamchenxin commentedon Nov 15, 2016
The reason of why
thisis set toundefinedfrombabel.why-is-this-being-remapped-to-undefined
Seems
thisshould be documented ?mscdex commentedon Nov 15, 2016
IMHO it shouldn't be documented so that users do not start relying on it instead of the proper
exports/module.exports.iamchenxin commentedon Nov 15, 2016
@mscdex Should it be documented for the difference between
strict modeand normal? or documented for prohibiting usingthisto export. Cause of there is some one use this to export previously.JacksonTian commentedon Nov 16, 2016
never be documented.
sam-github commentedon Nov 16, 2016
I don't like to encourage its use, but on the other hand, it is used, and if you use it by accident, and then want to understand why your code worked the way it does, its nice to find docs that explain that.
Put another way: if we hate
thisso much we don't want to document it... can we just remove it?I suspect it will break the world if removed... in which case, we won't remove it, so why not describe it, and also describe how it makes your code node-specific?
targos commentedon Jan 8, 2017
An option would be to document it as being deprecated, saying that
exportsshould be used instead.sam-github commentedon Jan 9, 2017
It should be documented so that if anybody finds code doing it, they can understand what is happening. It should also be doced as deprecated.
Any chance we can remove the feature, or is it harmless to leave in indefinitely? Will a future v8 update be likely to remove the feature for node? Would docs-deprecation be the first step to runtime deprecation?
TimothyGu commentedon Mar 6, 2017
Even though I've never seen this actually used, nor do I encourage it, my fear is that people might be actually using
this. And since we don't actually have a need to deprecate this, I'd support maintaining the status quo.The
thisbehavior is entirely implemented in JS and doesn't depend on any V8 specifics:node/lib/module.js
Line 571 in 51cea05
Note: the upcoming ES module implementation has
this === undefinedper spec, and since it's a completely different execution mode it doesn't change the behavior discussed here.gibfahn commentedon Mar 6, 2017
+1 to documenting as deprecated
niveditn commentedon Aug 11, 2017
Hey, I can help with this if given some pointers about what needs to be included. 🙂
Here's what I have so far:
exportsinsteadAlso which section of
/docs/api/modules.mdfile should it go in?Please let me know. Meanwhile I'll start on this.
Thanks!
BridgeAR commentedon Sep 23, 2017
@niveditn deprecations go into the
deprecations.md. I think it would be best if you just open a PR as soon as you personally have the feeling it is usable. If there are further improvements necessary they can be done in the open PR.niveditn commentedon Sep 25, 2017
Thanks for the info @BridgeAR! I will create the PR as soon as it has something usable.
doc: deprecate top-level `this`
doc: deprecate top-level `this`