Front end developer specialising in JavaScript and React. Experienced in all aspects of modern front end development. Passionate about making accessible, secure and performant software.
In the places where I've worked using JavaScript we've tended to use the method "export from a module and use it as import in another module". So if you want a quick answer this is what I would go for.
For the longer answer, there are pros and cons for each.
The second method sounds to me like dependency inversion. Dependency inversion is one of the SOLID principles. It means that we would have a special module purely to instantiate our other modules and their dependencies. For example, in your question, we would import the two modules there, instantiate the first one, and then instantiate the second one while passing in the first instance as a dependency. E.g. const secondModuleInstance = new SecondModule(firstModuleInstance);. That way our normal modules do not import and instantiate their dependencies directly.
Dependency injection is a way to automagically do dependency inversion. All the instantiations are done automagically for us and we just specify what dependencies everything has in some configuration file. An example package for this is InversifyJS.
Separation of concerns / principle of least knowledge / single responsibility principle. For good programming, we don't want our code to instantiate its own dependencies. That strongly couples modules together, makes testing difficult requiring us to mock (monkey patch) modules out, and balloons the code to include both dependency instantiation and logic.
Cost of dependency inversion:
Additional complexity to setup and use.
Non-idiomatic in JavaScript (except Angular).
Overall, in the scope of JavaScript applications, I don't believe things change frequently enough (the main motivation for dependency inversion) to justify the cost of implementing and using dependency inversion / injection.
An additional point. I recommend learning a bit more about programming principles and / or clean code practices. Even if you don't use them (e.g. we don't tend to use dependency inversion in JavaScript), knowing about them will make you a better programmer and better able to answer questions like these when they crop up in your projects.
In the places where I've worked using JavaScript we've tended to use the method "export from a module and use it as import in another module". So if you want a quick answer this is what I would go for.
For the longer answer, there are pros and cons for each.
The second method sounds to me like dependency inversion. Dependency inversion is one of the SOLID principles. It means that we would have a special module purely to instantiate our other modules and their dependencies. For example, in your question, we would import the two modules there, instantiate the first one, and then instantiate the second one while passing in the first instance as a dependency. E.g.
const secondModuleInstance = new SecondModule(firstModuleInstance);
. That way our normal modules do not import and instantiate their dependencies directly.Dependency injection is a way to automagically do dependency inversion. All the instantiations are done automagically for us and we just specify what dependencies everything has in some configuration file. An example package for this is InversifyJS.
Benefit of dependency inversion:
Cost of dependency inversion:
Overall, in the scope of JavaScript applications, I don't believe things change frequently enough (the main motivation for dependency inversion) to justify the cost of implementing and using dependency inversion / injection.
An additional point. I recommend learning a bit more about programming principles and / or clean code practices. Even if you don't use them (e.g. we don't tend to use dependency inversion in JavaScript), knowing about them will make you a better programmer and better able to answer questions like these when they crop up in your projects.
I recommend the programming first principles series (disclaimer: I wrote it) or popular books such as Clean Code and Code Complete.
Thank you for explaining in detail. I'll surely go through your series.