Skip to content

Require with a relative path should take into account it comes from a symbolic links #5481

Description

@julienw

Please have a look at this gist for context: https://gist.github.com/julienw/7c31988d43b639dcfde2

Basically we have 2 files in 2 different directories. Yet in one another directory we have 2 links to these 2 files. If file1 has require('./file2') it will fail because node's require is looking only in the "real" directory where file1 is. I suggest to augment this behavior to look both in this directory and where the symbolic link is located.

I understand it's not very easy to do given the current code as node doesn't keep track that it loaded the file from a symbolic link in the first place. I'd be happy to contribute with some guidance.

Activity

  1. added
    moduleIssues and PRs related to the module subsystem.
    feature requestIssues requesting new Node.js features.
    on Feb 28, 2016
  2. d3x0r commented on Feb 28, 2016

    @d3x0r
    Contributor

    have the outer define a prefix variable before requiring them? Or will they both get the modified result... like

    var here = __dirname;
    var LibPath = here + "/lib2";  // this doesn't start with a dot either (windows drive letter? network share?)
    require( "lib1/something.js" );
    LibPath = "./lib1"; // change to other directory for another
    require( "lib2/otherthing.js" )
    

    something.js
    require( LibPath + "config.js" )

    otherthing.js
    require( LibPath + "config.js" )


    I guess no....because LibPath is undefined....

  3. evanlucas commented on Feb 29, 2016

    @evanlucas
    Contributor

    Dupe of #3402?

    The module loader is locked. Introducing a breaking change to it would be a tough sell.

  4. julienw commented on Feb 29, 2016

    @julienw
    Author

    Actually in #3402 it's clearly said they don't want to change the behavior for relative paths (see especially #3402 (comment)). Which is my issue here. So it's quite different (and likely more difficult).

    The module loader is locked. Introducing a breaking change to it would be a tough sell.

    I understand. I can also totally imagine there is a lot of code that depends on this behavior because the behavior makes sense in a lot of cases as well.

    So maybe the main issue is the lack of configurability for the resolving mechanism. We can't change the locations where node seaches the dependencies.

    In my case, I want to run mocha on a directory that's made of symbolic linked files, that are not in the same source directory, but still the target directory's layout is what makes sense in my case, because it's the result of a build step.

    So for example I'd need to tell node "hey node, this is the root of the requires, please look here if you don't find your requirements elsewhere". But even this would not be quite right.

    Another way to look at it and that would work in my case, but is less generic because it requires the cooperation of the requiring script. If we keep track of where the parent of a script is (I think we do), we could propose either a specific prefix for the require argument (require('!parent/my/script.js') (we could also use top or root to denotate the root directory of the project, as other bugs are looking for), or a new function itself (requireParent('./my/script.js')).

  5. mattcollier commented on Mar 30, 2016

    @mattcollier

    New PR relevant to this issue here: #5950

  6. dlongley commented on Mar 30, 2016

    @dlongley

    @julienw,

    If PR #5950 is merged, then @kzc has suggested a workaround for you:

    #5950 (comment)

  7. julienw commented on Mar 31, 2016

    @julienw
    Author

    Thanks, I'll be sure to try this !

  8. kzc commented on Apr 26, 2016

    @kzc

    Thanks to @lamara and @dlongley, normal symlink behavior is now in the node 6.0.0 release.

    It makes module testing much simpler now - no need to copy files and reinstall modules.

  9. jasnell commented on May 13, 2016

    @jasnell
    Member

    fyi... because of regressions caused by #5950, a new commit putting it's changes behind a --preserve-symlinks flag was just committed to master today. It should hit in the next v6 minor. Closing this as there does not appear to be anything left to do

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

    feature requestIssues requesting new Node.js features.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