镜像站点 · 本页由第三方 GitHub 只读镜像提供，非 GitHub 官方站点，不接受任何登录或凭据输入。前往 github.com
Skip to content

>=1.6.2 break require('.') with NODE_PATH #1356

Closed
Closed
>=1.6.2 break require('.') with NODE_PATH#1356
Labels
moduleIssues and PRs related to the module subsystem.

Description

@a8m
a8m
opened on Apr 6, 2015

Running iojs until >=v.1.6.1 allow to use require('.')(i.e: index.js) with NODE_PATH.
Using >=v1.6.2 throw an error.

Example:

$ NODE_PATH=src node

// Start repl

> require('.')
Error: Cannot find module '.'
...
...

Could anyone please confirm this regression, so I could work on a fix.
Thx

Activity

  1. mscdex
    added
    confirmed-bugIssues and PRs for confirmed bugs.
    moduleIssues and PRs related to the module subsystem.
    on Apr 6, 2015

  2. a0viedo commented on Apr 6, 2015

    @a0viedo
    a0viedo
    on Apr 6, 2015
    Member

    I can't reproduce this in v1.6.3 nor v1.6.2. With v1.6.1 and v1.6.0 it throws the error Cannot find module '.'

  3. Fishrock123 commented on Apr 6, 2015

    @Fishrock123
    Fishrock123
    on Apr 6, 2015
    Contributor

    @a8m Are you trying to load a file whose whole name is .?

    as of v1.6.2 require('.') works the same as require('./').
    6fc5e95

  4. a8m commented on Apr 6, 2015

    @a8m
    a8m
    on Apr 6, 2015
    Author

    @a8m Are you trying to load a file whose whole name is .?

    No, require('.') means require('index'), i.e: directory.

    note that it's throw an error only when running node with NODE_PATH, and it works fine in <=1.6.1.
    (please see the example above)

  5. Fishrock123 commented on Apr 6, 2015

    @Fishrock123
    Fishrock123
    on Apr 6, 2015
    Contributor

    note that it's throw an error only when running node with NODE_PATH, and it works fine in <=1.6.1.
    (please see the example above)

    It should not work before io.js 1.6.2 because the commit which added the functionality is only in 1.6.2+ -- 6fc5e95

  6. a8m commented on Apr 6, 2015

    @a8m
    a8m
    on Apr 6, 2015
    Author

    Can you please run the example above @Fishrock123 ? (it also works on node 0.10)

  7. rlidwka commented on Apr 6, 2015

    @rlidwka
    rlidwka
    on Apr 6, 2015
    Contributor

    No, require('.') means require('index') as I know.

    require('.') means "require current directory". Same as require('./').

    Works for me as expected:

    $ cat > index.js
module.exports=1337
$ NODE_PATH=whatever iojs 
> require('.')
1337
  8. Fishrock123
    removed
    confirmed-bugIssues and PRs for confirmed bugs.
    on Apr 6, 2015

  9. silverwind commented on Apr 6, 2015

    @silverwind
    silverwind
    on Apr 6, 2015
    Contributor

    Well it looks like this was another undocumented feature, but it is a regression. Before the change one could do NODE_PATH=module iojs -p "require('.')" and get the equivalent of require('./module').

  10. silverwind
    added
    confirmed-bugIssues and PRs for confirmed bugs.
    on Apr 6, 2015

  11. a8m commented on Apr 6, 2015

    @a8m
    a8m
    on Apr 6, 2015
    Author

    On which version are you testing it ? @rlidwka

  12. silverwind commented on Apr 6, 2015

    @silverwind
    silverwind
    on Apr 6, 2015
    Contributor

    This 'feature' looks to be broken by simply setting more than one path in NODE_PATH:

    On 1.6.1 (with both module1 and module2 being folders in the current dir):

    $ export NODE_PATH=module1,module2
$ iojs -p 'require(".")'
module.js:318
    throw err;
          ^
Error: Cannot find module '.'

    Not sure if it's worth to fix, considering it is undocumented and won't work with more than one module dir specified.

  13. Fishrock123 commented on Apr 6, 2015

    @Fishrock123
    Fishrock123
    on Apr 6, 2015
    Contributor

    @a8m what is the use-case for the previous behavior?

  14. silverwind commented on Apr 6, 2015

    @silverwind
    silverwind
    on Apr 6, 2015
    Contributor

    I'm leaning towards that the current behaviour logically more correct, and would consider the old behavior as a bug, because you'd expect that require('.') would get you the module in $PWD and not the module in the first (and only) path in $NODE_PATH.

    Also, $NODE_PATH seems not to be intended to actually contain a module in its root, but subdirectories with modules.

  15. 13 remaining items

  16. monsanto commented on Apr 7, 2015

    @monsanto
    monsanto
    on Apr 7, 2015
    Contributor

    I can't understand the calls for revert. This is a super duper edge case, and it was known at the time of applying the require('.') patch that--surprise--the behavior of require('.') was going to subtly change. The churn of the patch, the revert, and applying the patch again dwarfs the trouble of making someone fix their application that they need to fix anyway.

    I have no stake in this particular issue, I just don't want to set a precedent for iojs of reverting intentional changes at the drop of a hat. It would be nice to know if I see something cool in the changelog, that I can count on it being available a month later. If you are going to change the behavior, stick to it.

  17. rvagg commented on Apr 7, 2015

    @rvagg
    rvagg
    on Apr 7, 2015
    Member

    I agree @monsanto, reverting is my least favourite option here by far

  18. a8m commented on Apr 7, 2015

    @a8m
    a8m
    on Apr 7, 2015
    Author

    Thanks @monsanto

    This is issue in not about the design of require, if it's good or bad practice, or how to use it.
    It's about regression.
    This break people's production code, and it shouldn't.(at least in a patch-version).

    For this reason, I'll be +1 on reverting and landing it in v2.0.

  19. petkaantonov commented on Apr 7, 2015

    @petkaantonov
    petkaantonov
    on Apr 7, 2015
    Contributor

    This break people's production code, and it shouldn't.(at least in a patch-version).

    This is preposterous because this issue scores all three of:

    1. Affects a very small amount of users
    2. Is not an intended feature, might even be a bug
    3. Is trivial to fix for the affected users

    Strictest semver would not consider these at all which means every change, no matter what, must increment a major which would obviously make it pointless to use the scheme in the first place.

    Therefore in practice when something follows a semver, it doesn't follow it strictly but considers some combination of the factors.

  20. a8m commented on Apr 7, 2015

    @a8m
    a8m
    on Apr 7, 2015
    Author

    I'll think you get me wrong, I'm not fan of this "feature" and not use it actually.
    but some people does(the amount is pointless), and since this "bug" lives outside more than two years, I prefer to catalog it as a "feature".

  21. silverwind commented on Apr 7, 2015

    @silverwind
    silverwind
    on Apr 7, 2015
    Contributor

    I have the fix for this almost ready. The only uncertainty is precedence. Should require('.') give the module in PWD or the one in NODE_PATH if both exist?

  22. Fishrock123 commented on Apr 7, 2015

    @Fishrock123
    Fishrock123
    on Apr 7, 2015
    Contributor

    @silverwind Doesn't NODE_PATH essentially overwrite what would be the CWD?

  23. silverwind commented on Apr 7, 2015

    @silverwind
    silverwind
    on Apr 7, 2015
    Contributor

    @Fishrock123 no, the array of search paths is just extended and paths in NODE_PATH are put in front:

    https://github.com/iojs/io.js/blob/v1.x/lib/module.js#L474

  24. silverwind commented on Apr 7, 2015

    @silverwind
    silverwind
    on Apr 7, 2015
    Contributor

    require('./') is a special case that doesn't use search paths at all. With my fix, require('.') would need to use search paths, and my current approach is to add PWD either in front or in the end of that path array.

  25. a8m commented on Apr 7, 2015

    @a8m
    a8m
    on Apr 7, 2015
    Author

    Should require('.') give the module in PWD or the one in NODE_PATH if both exist?

    NODE_PATH

  26. silverwind commented on Apr 7, 2015

    @silverwind
    silverwind
    on Apr 7, 2015
    Contributor

    NODE_PATH

    Is that really needed? Does your PWD contain another module? It would complicate the fix quite a lot. The search paths used by require are

    [/* NODE_PATH paths */, /* node_modules etc. */]

    That array is created on startup, and I can't easily discern paths inserted by NODE_PATH from regular paths, and there is the possibilty that NODE_PATH changes during runtime. I'd much prefer just inserting PWD at position 0 if require(.) is used.

  27. a8m commented on Apr 7, 2015

    @a8m
    a8m
    on Apr 7, 2015
    Author

    As far as I know, this shouldn't work when NODE_PATH changes during runtime.

    Is that really needed? Does your PWD contain another module? It would complicate the fix quite a lot.

    You can play with it yourself (by comparing >=1.6.2 against <=1.6.1). like so.

  28. silverwind
    added a commit that references this issue on Apr 16, 2015

    module: handle NODE_PATH in require('.')

    3ad82c3

  29. silverwind commented on Apr 16, 2015

    @silverwind
    silverwind
    on Apr 16, 2015
    Contributor

    Fixed by 3ad82c3. Note that this usage will print a single deprecation warning on first use, and will be removed in 3.0.0, as it stands now.

  30. silverwind
    closed this as completedon Apr 16, 2015
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

    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