Skip to content

Tricky issue with Require() #23144

Description

@cornopaez
  • Version:v10.9.0
  • Platform:Linux station-name 4.15.0-1023-azure Simple project messaging. #24-Ubuntu SMP Tue Aug 28 17:35:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
  • Subsystem: Not known

Hello all,

I'm noticing a tricky issue that may be hard to explain. At a high level, it seems as though require() struggles with recently moved/renamed files.

I'm seeing this issue when trying to require some functions from files within the same folder. I have three files, two with identical contents (ctrl-a, ctrl-c, ctrl-v between files) in the same folder: a.js, copy-of-a.js, and b.js. I require functions from these files elsewhere with the following code:

const {someFunction, someOtherFunction, etc} = require('../../middlewares/a.js')

Both a.js and copy-of-a.js have functions required in b.js and vice versa: b.js has some functions required in a.js and copy-of-a.js. All paths are correct, as no errors are seen for missing files.

Here's where things get weird. Calling a function in b.js that itself uses a requires function from a.js will yield an error stating TypeError: someFunction is not a function along with the stack trace of where the error occurred. Updating the code to require the same function from copy-of-a.js instead works just fine.

I'm not sure that I have can do to provide more information about this behavior. All I can think of is that I had recently run the following command to rename a.js from something else:

mv someOldName.js a.js

Even this is theory is thin. Refactoring the require() from other files to point to the new name works just fine. In my eyes the only difference between the two a files is that one is brand new and the other one has been around for a while.

Any suggestions on how to provide more information to properly see where the issue may lay?

Thanks!

Activity

  1. mscdex commented on Sep 28, 2018

    @mscdex
    Contributor

    Can you provide a simple, complete example that reproduces the issue?

  2. Fishrock123 commented on Sep 28, 2018

    @Fishrock123
    Contributor

    Are you just seeing the require() cache?

  3. richardlau commented on Sep 28, 2018

    @richardlau
    Member

    Without a concrete example it's hard to say, but it sounds like you have a cyclic module dependency: https://nodejs.org/dist/latest-v10.x/docs/api/modules.html#modules_cycles

    When main.js loads a.js, then a.js in turn loads b.js. At that point, b.js tries to load a.js. In order to prevent an infinite loop, an unfinished copy of the a.js exports object is returned to the b.js module. b.js then finishes loading, and its exports object is provided to the a.js module.

  4. cornopaez commented on Sep 28, 2018

    @cornopaez
    Author

    Thank all for your prompt responses. I believe @richardlau may have hit it in the head: I have circular require() calls in the affected modules.

    Because I'm a n00b and this is the first time I've run into this issue stemming from poor planning on my part, I'd like to as for some input on this: what's the best way to address this?

    I know that this is not the best forum for this but at this time I have your attention :)

  5. Fishrock123 commented on Sep 28, 2018

    @Fishrock123
    Contributor

    Here are two possibilities:

    A

    Move around the require calls. Some, but certainly only a few, such problem come from the order of imports.

    B

    Have one of the module lazy-load it's dependencies.
    That is, actually require them the first time some exported function is run.

  6. TomCoded commented on Sep 29, 2018

    @TomCoded
    Contributor

    IMHO, the first step is to think carefully about the high level design of the program, specifically in the context of the dependency inversion principle. If you really need both modules to know about each other on some level, consider setting up a module that does the orchestration between both of them, for example. You may be able to change to this model relatively easily and reap its benefits, including better dependency management.

  7. cornopaez commented on Oct 1, 2018

    @cornopaez
    Author

    Again, thank you all for your input. This is invaluable to me.

  8. apapirovski commented on Oct 18, 2018

    @apapirovski
    Contributor

    Sounds like this has been addressed now. I'm going to close it out as I'm trying to keep the issue tracker tidy but please feel free to reopen.

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions