Haul: Haul packager updates are very slow to load

[dphaener]

Current Behavior

When making a change to my source code and reloading, the app takes 5-10 seconds to actually download the changes and restart the app (this is after a 10 second webpack rebuild).

Expected Behavior

The reloading should be just as fast as it is when using the metro bundler (nearly instantaneous)

Haul Configuration (webpack.haul.js)

import { createWebpackConfig } from 'haul';
import merge from 'webpack-merge';

const ALIASED_MODULES = [
  'react-native-linear-gradient',
  'galmorous-react-native',
  'react-native-svg',
  'lottie-react-native',
  'react-navigation',
];

export default {
  webpack: env => {
    const config = createWebpackConfig(({ platform }) => ({
      entry: ['babel-polyfill', `./index.${platform}.js`],
    }))(env);

    const moduleAliases = ALIASED_MODULES.reduce((acc, moduleName) => {
      acc[moduleName] = path.resolve(`./node_modules/${moduleName}`);
      return acc;
    }, {});

    const customConfig = {
      resolve: {
        symlinks: false,
        alias: moduleAliases,
      },
    };
    // eslint-disable-next-line no-useless-escape
    const customExclude = /node_modules(?!.*[\/\\](react|pretty-format|haul|metro|shared-mobile|glamorous-native|static-container))/;

    // Create a custom webpack configuration based on a deep merge of the default
    // configuration and our custom build settings from above.
    const jsLoader = config.module.rules.find(
      rule => rule.test && rule.test.test('foo.js')
    );

    jsLoader.exclude = customExclude;
    jsLoader.use.find(loader =>
      loader.loader.includes('thread')
    ).options.workerParallelJobs = 50;

    const mergedConfig = merge(config, customConfig);
    return mergedConfig;
  },
};

Your Environment

| software | version
| ---------------- | -------
| Haul | 1.0.0-rc.9
| react-native | 0.57.4
| node | 10.0.0
| npm or yarn | 6.4.1

[tido64]

I had a look at this today since we're having the same issues. For our app, it takes between 6-12 seconds to reload, even when you manually trigger one.

As it turns out, what takes the most time is:

• A stringify call on the entire bundle here: compiler/worker/initWorker.js:30
• Which gets sent over a WebSocket connection to the main process
• … to be parsed here: compiler/Fork.js:85
• … before it gets sent to the device (?)

It seems that the reason we're doing it this way is to be able to have an in-memory file system and cache everything in memory. But I wonder if it would be a lot faster if we simply wrote to disk, pass a file path instead, and simply read the file from the main process. Our debug bundle size is close to 30 MB, and I don't think the current implementation is ideal for bigger bundles.

Any thoughts on this?

[thymikee]

Storing the bundle in tmp dir should definitely be better than passing it between workers. cc @zamotany

[zamotany]

Yeah we can do that. Anyone interested in contributing? I can provide some guidance if needed.

[tido64]

I can try taking a stab at it over the weekend if nobody has picked it up by then.

[dphaener]

FWIW, this is no longer relevant for me, as I abandoned Haul in favor of metro with a custom configuration to suit my needs.

[apexskier]

512 has definitely fixed this for me, in my opinion this can definitely be closed (now or when the next release is made)

[thymikee]

The latest release is up for grabs with your last PR merged @apexskier :)

[grahamlyus]

Yeah we can do that. Anyone interested in contributing? I can provide some guidance if needed.

I don't see any activity on this, I'm happy to have a go so to avoid filling my root directory with bundles and hot updates, even though I've put them in my .gitignore

Any pointers on how to get the output into a build folder or TMPDIR?

[thymikee]

Update to the latest RC.12