Sitelet https://github.com/nodejs/node/issues/9623
Skip to content

should the fact that this is bound to module.exports be documented? #9623

Description

@sam-github
% node -p 'require("./f.js")'
{ fu: 'hi' }
% cat f.js
this.fu = 'hi'

This is not documented, should it be?

cf. #9622 (comment) and earlier comments

Activity

  1. iamchenxin commented on Nov 15, 2016

    @iamchenxin
    Contributor

    test with "babel-plugin-transform-es2015-modules-commonjs": "^6.18.0"
    this is set to undefined.

  2. iamchenxin commented on Nov 15, 2016

    @iamchenxin
    Contributor

    The reason of why this is set to undefined from babel.
    why-is-this-being-remapped-to-undefined
    Seems this should be documented ?

  3. mscdex commented on Nov 15, 2016

    @mscdex
    Contributor

    IMHO it shouldn't be documented so that users do not start relying on it instead of the proper exports/module.exports.

  4. added
    moduleIssues and PRs related to the module subsystem.
    questionIssues asking questions about Node.js.
    and removed on Nov 15, 2016
  5. iamchenxin commented on Nov 15, 2016

    @iamchenxin
    Contributor

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

  6. JacksonTian commented on Nov 16, 2016

    @JacksonTian
    Contributor

    never be documented.

  7. sam-github commented on Nov 16, 2016

    @sam-github
    ContributorAuthor

    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?

  8. targos commented on Jan 8, 2017

    @targos
    Member

    An option would be to document it as being deprecated, saying that exports should be used instead.

  9. sam-github commented on Jan 9, 2017

    @sam-github
    ContributorAuthor

    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?

  10. TimothyGu commented on Mar 6, 2017

    @TimothyGu
    Member

    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:

    var result = compiledWrapper.apply(this.exports, args);
    . So no, I don't think so.

    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.

  11. gibfahn commented on Mar 6, 2017

    @gibfahn
    Member

    +1 to documenting as deprecated

  12. added
    good first issueIssues that are suitable for first-time contributors.
    on Jul 30, 2017
  13. niveditn commented on Aug 11, 2017

    @niveditn
    Contributor

    Hey, I can help with this if given some pointers about what needs to be included. 🙂

    Here's what I have so far:

    1. Code snippet demonstrating the behaviour
    2. Deprecation warning
    3. Briefly explain the reason for this code behaviour
    4. Recommend using exports instead

    Also which section of /docs/api/modules.md file should it go in?

    Please let me know. Meanwhile I'll start on this.

    Thanks!

  14. removed
    questionIssues asking questions about Node.js.
    on Sep 23, 2017
  15. BridgeAR commented on Sep 23, 2017

    @BridgeAR
    Member

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

  16. niveditn commented on Sep 25, 2017

    @niveditn
    Contributor

    Thanks for the info @BridgeAR! I will create the PR as soon as it has something usable.

  17. added a commit that references this issue on Feb 1, 2018
  18. added a commit that references this issue on May 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    good first issueIssues that are suitable for first-time contributors.moduleIssues and PRs related to the module subsystem.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions