Why is the "getModules" function only available in DEV mode?

[doodlez79]

Good afternoon, we wanted to use “getModules” in the Production build of metro, but it’s not there. Tell me why it cannot be used in the Prod assembly? Is it possible to remove it from the DEV flag?

[robhogan]

Hi @doodlez79 - it's gated behind __DEV__ here - it's one of several dev-only APIs.

metro/packages/metro-runtime/src/polyfills/require.js

Lines 530 to 539 in c3aec55

	if (__DEV__) {
	// $FlowFixMe[prop-missing]
	metroRequire.Systrace = {
	beginEvent: (): void => {},
	endEvent: (): void => {},
	};
	// $FlowFixMe[prop-missing]
	metroRequire.getModules = (): ModuleList => {
	return modules;
	};

Even if we exposed getModules in production, the entries returned would be lacking a few things, like full module path mappings, that we don't incorporate into the prod bundle for size reasons.

Can I ask what your use case is for prod use?

[robhogan]

IIRC @EvanBacon was interested in this API (and forked the polyfill to get it) - happy to expose something but ideally we'll keep the API minimal to fit what folks need.

[doodlez79]

Good afternoon, we are releasing a split application into small pieces using metro bundler. For security, we want to check the existence of a particular module by identifier.

[robhogan]

So in principle, hasModule(moduleId): boolean would work for you?

If you're using asyncRequire, isn't there a possibility that a module is loading, but not yet loaded due to some other async request? My sense is that it'd be better to track which bundle segments are available/loading/loaded in your async require logic, but a bit more detail might help understand the use case here.

[doodlez79]

Hi, I think hasModule would solve our problem.

[robhogan]

And what about the multiple async loading issue? Or is that not your use case?

If we're exposing/creating a new public API here a bit more detail on why it's needed would be really helpful.

[doodlez79]

We're building codeSpliting into existing large codebase applications where we've already built in full assembly file loading, but are gradually moving to dynamically loading smaller modules on demand. And we add a check for the existence of the module, so that when we have one bundle, it does not try to download anything, but immediately returns it to the user.

For our application, we made a service that returns a list of modules and dependencies, if we have the same modules in our dependencies, then we really might have a problem. We create an object in which we store the key (moduleId), and the value is the loading state of this module (promise), and if two modules depend on the same module, then one will download it, and the other must wait for the end of its loading.

And hasModule will allow you to check the existence of this module and prevent unnecessary trips to the network for modules!