Dynamic import not working

[jarecsni]

There has been a conversation around this problem on different thread, please see:
facebook/react-native#6391 (comment)

The problem is essentially that as of now it is not possible to import or require modules dynamically or programatically (using a variable).

With import() in Stage 3 in TC39 this feature is fast becoming a standard language element and the lack of this facility in React Native is becoming all the more limiting.

Also, as per the above conversation there are very legitimate scenarios (dependency injection for example), where such lazy and conditional loading is a must.

Based on all this I would like to make a feature request for this (please let me know if this is not the right forum for doing so).

[cpojer]

@jeanlauliac can discuss more about the plans for this.

[jeanlauliac]

We plan on adding the import('foo') syntax to be able to load modules asynchronously, paving the way of being able to download part of the code on-demand, for example. This is something I'd love to happen towards the end of the year.

However, we have no plans to support non-static imports in general, whether it's a require(foo) or import(foo) where foo is a variable which value isn't known at bundling time. One reason I could point out, in particular, is that dynamic imports cannot be typecheked with Flow anyway (and I'd be surprised they are with Typescript either, but I haven't checked). Another reason is that we'd have to be over-eager when bundling, and include all the JS files, that would cause bigger bundles.

We could theoretically typecheck & support dynamic requires under the condition that the list of possible modules to be imported is known at bundling time, though it's not clear what syntax would express that. What I've seen in some projects to workaround this, for example for routing systems, is to have each require explicit. Ex.

{
  routeName: 'foo',
  view: () => require('SomeComponent'),
},
{
  routeName: 'bar',
  view: () => require('SomeOtherComponent'),
}

That is effectively equivalent to having 'dynamic' requires with a list of fixed possibilities, but more verbose. It would be possible, for one who wishes, to implement a Babel transform that'd make that less verbose.

[jarecsni]

@jeanlauliac Thanks for explaining the background! I think what you describe toward the end is exactly what people (including me) expect to happen: 1) provide a way to inform the packager which modules are potentially imported 2) support dynamic (programmatic) import of those declared in point 1. As you point out, type checking would work, bundle size would not be an issue.

Since dynamic (variable) imports will be part of the language, can RN afford not to provide some form of support?

[jeanlauliac]

Yes, even though I said we have no plans internally to implement it, I'd love RN to provide some form of support for this ^_^ We have no plans ourselves because we don't have a use case requiring that right now, and are busy with other issues, but I'm happy to look at proposals/PRs.

For example we could imagine some opt-in configuration setting that makes packager include all source files from a particular directory into a bundle, regressing build duration and bundle size but allowing for a form of dynamic require. It believes in need to be opt-in as it causes these regressions. Then we would have to figure out how numeric module IDs are handled in such a model.

[jarecsni]

Ok fair enough. I will have a think about it (I am not familiar with RN packager etc. so it may be a bit of a learning curve for me but then again, it is something I would love to use, so ... :))

[steveccable]

Is this being actively looked at/worked on by anyone at this point? This is still a feature I would very much like to see in RN, and was actually surprised not to have in the first place.

[jeanlauliac]

Is this being actively looked at/worked on by anyone at this point? This is still a feature I would very much like to see in RN, and was actually surprised not to have in the first place.

• Being able to dynamic require at runtime: no, this isn't being worked on right so far as I know.
• Being able to ignore dynamic requires (such as in moment.js) and have them throw at runtime, or replace them by static requires: this is already possible by having a custom babel transform that replaces dynamic requires by some code that throws, or just does nothing.

I'd like to publish some simple module to allow people to do the second case easily.

[sneerin]

This bug limit to numbers of really popular libraries like e.g. moment/moment#3624 i saw similar other items with same issue

[camdagr8]

This is a huge bummer for me. I'm trying to take a Domain Driven Design approach with my RN app where each screen components have a predictable file structure:

--index.js
--actions.js
--actionTypes.js
--reducers.js

Then have a main reducers.js file that runs a loop that requires each file and automatically makes it available in the export default {...aggregatedReducersObject}

This approach simplifies our development process and reduces the number of times we've had compile errors because someone forgot to include their actions/reducers/etc into the aggregated files.

As a work around, I'm running a gulp watch on the components directory, then writing to my aggregated file on creation/delete. I hate doing it this way as there are often times when the gulp watch craps out or there's race conditions that spring up when editing that causes a need for a restart of both my gulp watch and RN.

[jeanlauliac]

Then have a main reducers.js file that runs a loop that requires each file and automatically makes it available in the export default {...aggregatedReducersObject}

I'm curious: how do you get the list of files to require, do you use readdir?

[camdagr8]

@jeanlauliac Yes, I use readdir via a custom CLI for the project that generates components/assets/libraries and adds the file names to the aggregated object.

It ends up looking like this:

export default {
    Login: {
        redux:  {
            state:       require('./components/screens/Login/state').default,
            actionTypes: require('./components/screens/Login/types').default,
            actions:     require('./components/screens/Login/actions').default,
            reducers:    require('./components/screens/Login/reducers').default,
            services:    require('./components/screens/Login/services').default,
        },
        screen: require('./components/screens/Login').default,
    },
    Home: {
        screen: require('./components/screens/Home').default,
    }
}

Then I use react-native-navigation to register the screens:

import registry from './registry';

// Redux setup
let actionTypes = {};
let actions  = {};
let reducers  = {};
let services = {};
let state = {};


Object.values(registry).forEach((item, i) => {

    if (!item.hasOwnProperty('redux')) { return; }

    let k = Object.keys(registry)[i];

    if (item.redux.hasOwnProperty('actionTypes')) {
        actionTypes = Object.assign({}, actionTypes, item.redux.actionTypes);
    }

    if (item.redux.hasOwnProperty('actions')) {
        actions[k] = item.redux.actions;
    }

    if (item.redux.hasOwnProperty('reducers')) {
        reducers[k] = item.redux.reducers;
    }

    if (item.redux.hasOwnProperty('state')) {
        state[k] = item.redux.state;
    }

    if (item.redux.hasOwnProperty('services')) {
        services[k] = item.redux.services;
    }
});

// Create the store
const createStoreWithMiddleware = applyMiddleware(thunk)(createStore);
const store = createStoreWithMiddleware(combineReducers(reducers), state);

// Register screens and create tabs
let tabs = [];

Object.values(registry).forEach((item, i) => {

    if (!item.hasOwnProperty('screen')) {
        return;
    }

    let k = Object.keys(registry)[i];
    Navigation.registerComponent(`app.${k}`, () => item.screen, store, Provider);

    if (item.hasOwnProperty('tab')) {
        tabs.push(item.tab);
    }
});

[jeanlauliac]

I was asking because readdir would be even more of a stretch to support by default, there's no concept of filesystem anymore at runtime. I think the way you approach this, by generating an aggregated module, is correct. But ideally the bundler would be able to generate it on-demand rather than it being a separate build step.

[serhiipalash]

For example we could imagine some opt-in configuration setting that makes packager include all source files from a particular directory into a bundle

You can do this with babel-plugin-wildcard https://www.npmjs.com/package/babel-plugin-wildcard

It works for us in production.

[camdagr8]

@serhiipalash I'll have to give this a look. Thanks!

[serhiipalash]

@camdagr8 I don't know how this plugin works, but we have folder with these files

translations/
   en.json
   de.json

I think it replaces our

import * as translations from '../../translations'

on this

import de from '../../translations/de'
import en from '../../translations/en'
const translations = { de, en }

And it does this before React Native packager started. If you add more files in translations folder after React Native packager start (during development), it will not know about them until you restart it.
In production as we don't have such case - read dynamic new files during runtime, we can use it.

[simonbuchan]

Webpack does this by parsing the module expression and bundling everything it could require

Typescript has been coming at typing modules for a while, but the current closest issue would be microsoft/TypeScript#14844

[deecewan]

Another reason is that we'd have to be over-eager when bundling, and include all the JS files, that would cause bigger bundles

I think that not implementing this because it could blow out bundle sizes is like saying you're not going to support node_modules, because too many modules will blow out bundle size. Webpack allows this, but doesn't encourage it. If a developer plans on using this, of course the burden is on the developer to mitigate bundle size issues.

One place I'd like this is in importing translation files. They all sit in the same place, and if I could use a variable, I could do something like

import(`translations/${locale}.json`)

In this case, eagerly loading the whole folder is not just a side-effect, but the intention, given the alternative of

const translations = {
  en: import(`translations/en.json`),
  de: import(`translations/de.json`),
  'en-US': import(`translations/en-US.json`),
};

And so on for more languages as my service scales out.

Not only that, but I also need to load locale data, both for the Intl polyfill and for react-intl. I end up having three lists that do nothing but contain imports for every file in three different folders. If anything, that'll increase bundle sizes more, because of all the code sitting there to fill the void of dynamic imports.

Additionally, it'd be nice to be able to import via http. For instance, instead of bundling all translations with my application and increasing download for people who only need one language, have

const translations = await import(`https://some-s3-url.com/translations/${locale}.json`);

and similarly with the locale data that also needs to be loaded.

[simonbuchan]

Importing unbundled code is a very interesting use-case that would in the general case need to implement https://whatwg.github.io/loader/

I've gotten surprisingly far by simply combining fetch() and eval(), some simplified code:

const externals = {
  react: require('react'),
  'react-native': require('react-native'),
};
async function fetchImport(url) {
  const res = await fetch(url);
  const source = await res.text();

  let exports = {};
  const module = { exports };
  const require = id => {
    if (!(id in externals)) throw new Error(`Module not found: ${id}`);
    return externals[id];
  };
  eval(source);
  return module.exports;
}

The main problem with this is that error stacks in (at least android) JSC don't include frames from eval'd code at all, even with \n//# sourceURL=${url} appended (which works when using the remote debugger)

[jeanlauliac]

I've left the project since then so I'm not 100% sure of the current state, but I think there's some partial support. @rafeca, @rubennorte, do you know if there is any possibly import() support in OSS Metro?

[markwongsoontorn]

Being able to dynamically load dependencies would make a huge difference, webpack already has this supported, I'd like to see this happen sometime in the near future.

[MarcoMacedoP]

Is there any update status for this issue?

[pvanny1124]

Bump. It would be extremely nice to have the ability to do this.

[slorber]

It's not totally related, but wanted to mention here that optional requires are now possible. Not sure how but this might enable a workaround for some people interested by this feature? react-native-community/discussions-and-proposals#120 (comment)

[tastycode]

Looks like this would be a solution for local loading of certain kinds of content, e.g. @benbucksch 's use-case for translation files. https://github.com/itinance/react-native-fs

[chinomnsoawazie]

Bump. This feature is really important....

[chybisov]

Another reason is that we'd have to be over-eager when bundling, and include all the JS files, that would cause bigger bundles

I think that not implementing this because it could blow out bundle sizes is like saying you're not going to support node_modules, because too many modules will blow out bundle size. Webpack allows this, but doesn't encourage it. If a developer plans on using this, of course the burden is on the developer to mitigate bundle size issues.

One place I'd like this is in importing translation files. They all sit in the same place, and if I could use a variable, I could do something like

import(`translations/${locale}.json`)

In this case, eagerly loading the whole folder is not just a side-effect, but the intention, given the alternative of

const translations = {
  en: import(`translations/en.json`),
  de: import(`translations/de.json`),
  'en-US': import(`translations/en-US.json`),
};

And so on for more languages as my service scales out.

Not only that, but I also need to load locale data, both for the Intl polyfill and for react-intl. I end up having three lists that do nothing but contain imports for every file in three different folders. If anything, that'll increase bundle sizes more, because of all the code sitting there to fill the void of dynamic imports.

Additionally, it'd be nice to be able to import via http. For instance, instead of bundling all translations with my application and increasing download for people who only need one language, have

const translations = await import(`https://some-s3-url.com/translations/${locale}.json`);

and similarly with the locale data that also needs to be loaded.

This is really important use case.

[biancadragomir]

Are there any updates or any solutions? We really need to require conditionally because of integrating Huawei packages. They will be available on devices with Huawei services, but unavailable on all the others. This is really a blocker 😢

[deecewan]

you can already do conditional requires @biancadragomir IIRC.

if (HUAWEI_DEVICE) {
  require('huawei-packages');
}

this issue is specifically about not being able to use runtime-evaluated strings as import locations, for instance if you wanted to do:

const manufacturer = getManufacturerName();
require(`${manufacturer}-packages`);

edit: in fact #52 (comment) mentions it specifically - react-native-community/discussions-and-proposals#120 (comment) mentions it's released.

[biancadragomir]

@deecewan we are doing that already. But we are using a tool called handpick to exclude the huawei dependencies from normal builds. the problem is that for normal builds (non-huawei), that package isn't available and there's a crash when the build happens since the packager resolves all the "require(...)" from the project, regardless of the if branch they are on.

[jiangleo]

You can try metro-code-split https://github.com/wuba/metro-code-split .
it provides Dll and Dynamic Imports features.

[iamonuwa]

Do not import/require the package at the top of the file.
Require it inside the function that it will be used in.

[pke]

You can do this with babel-plugin-wildcard npmjs.com/package/babel-plugin-wildcard

It works for us in production.

It does not work in dev mode since the resolved files are cached by metro. Any changes to them or adding removing will not be recognised. I wonder if there is a metro setting to exclude certain file patterns from being cached?

[jd1378]

I switched to re-pack which uses webpack 5 to bundle your app
I'm happy with it so far

[VityaSchel]

I switched to re-pack which uses webpack 5 to bundle your app I'm happy with it so far

tell expo developers to switch to it too pls

[karlhorky]

One place I'd like this is in importing translation files. They all sit in the same place, and if I could use a variable, I could do something like

import(`translations/${locale}.json`)

Since metro@0.72.1, there is an experimental require.context() implementation by @EvanBacon

const translationsContext = require.context(
  // Relative path to the directory containing the translations
  './translations',
  // Include subdirectories?
  false,
  // Regular expression files filter (eg. only include JSON files)
  /\.json$/,
);

translationsContext(`./translations/${locale}.json`)

This implementation is based on the require.context() feature in webpack