Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tricky issue with Require() #23144

Closed
cornopaez opened this issue Sep 28, 2018 · 8 comments
Closed

Tricky issue with Require() #23144

cornopaez opened this issue Sep 28, 2018 · 8 comments

Comments

@cornopaez
Copy link

cornopaez commented Sep 28, 2018

  • 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!

@mscdex
Copy link
Contributor

mscdex commented Sep 28, 2018

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

@Fishrock123
Copy link
Contributor

Are you just seeing the require() cache?

@richardlau
Copy link
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.

@cornopaez
Copy link
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 :)

@Fishrock123
Copy link
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.

@TomCoded
Copy link
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.

@cornopaez
Copy link
Author

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

@apapirovski
Copy link
Member

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants