在 nodejs 中链接导入和导出

Question

I'm looking to set up a file structure such that I have a 'modules' file which exports a bunch of... modules.

I know that in general, any required module is cached and so not read/executed after its first import, but I'm wondering if this stands true for a chain of imports/exports, where their root import has been exported as a defined constant.

eg.

// modules.js
const fs = require('fs');

module.exports = {
  fs
};

------------------

// file1.js
const { fs } = require('modules.js');

------------------

// file2.js
const { fs } = require('modules.js');

Do file1 and file2 receive the same cached copy of fs? This is important because some of my modules require initialization and I don't want this code being executed multiple times.

PS The whole point of this is so that I can have a single location to require specific modules from. If there's a better way to do this, please school me!

Thanks in advance.

Answer 1

Do file1 and file2 receive the same cached copy of fs ? This is important because some of my modules require initialization and I don't want this code being executed multiple times.

Yes, modules are cached. So, unless you manually reach into the cache to remove a module from the cache, an already initialized module will just be fetched from the cache on the 2nd, 3rd, 4th, etc... times it is loaded. It will only be initialized once. This is a fundamental (and very useful) part of the node.js module design philosophy.

The whole point of this is so that I can have a single location to require specific modules from. If there's a better way to do this, please school me!

I would strongly discourage you from doing something like you show in your question. If you need the fs module, then just include the fs module directly. There is no savings for doing it the way you propose and it only obscures the real dependencies and ties modules together in ways that makes them harder to reuse individually. The whole point of modularity is that you can build small to medium sized chunks of separate, reusable and testable code that aren't interwoven with the rest of your code and clearly spell out their own dependencies. Linking things to some intermediate modules module just obscures all that and creates ties between things when that is not necessary. It also can complicate individual module testing.

Look at what typically happens. You start creating the modules module. FileA needs four things in it so you put those four things in it. FileB needs 3 common ones, but two other ones. So, now you have 6 things in the modules module. But, you've now made FileA depend on 2 modules in the modules module that it doesn't really depend on and FileB now depends on 1 module in the modules module that it doesn't really depend on. Extend this a few more ways and you quickly have a big mess of false dependencies. To actually reuse a given module in another project, you've now got to pull in a lot more than is really necessary. In any sort of larger project this can get messy real quickly.

Even if you only ever use the module module in cases where another module needs everything in it, what have you actually gained over just specifying the modules you actually need in the module that needs them? You've attempted to save a small amount of typing, but complicated the cleanliness of your dependencies and simplicity of reuse. IMO, not the correct tradeoff.

For some reason which seems to happen to many when they first start programming on node.js (but the full reasoning isn't entirely clear to me), many people find they want to avoid manually typing the module dependencies at the start of each module. Perhaps it's the notion that we shouldn't ever be repeating lines of code so the 2nd and 3rd time we go to type similar module dependencies into the start of a new module, we have an urge to encapsulate that in some common code. That's generally a good notion to follow, but not in this specific case because of the compromise to modularity and independence and testability. I think it's just something to get used to when programming with node.js modules and is the better way to code your modules. Don't create intermediate aggregation modules that add no real value and just obscure the actual dependencies.