Dynamic imports and import directory

Hi all!

I’m trying to use dynamic imports for my app to reduce the client bundle size, as currently the execution takes longer than I’d like on mobile devices.

My app is built using the pre-1.3 style, without using an imports directory. Will I need to move all of my client side code to the imports directory to take advantage of dynamic imports?

Currently, all the atmosphere packages I’ve added get included in the client bundle. Do they only get included in the client bundle if I explicitly import them when using the imports directory?

At the moment, the only way to avoid eager loading of code is by using the imports/ folder. So, in a nutshell, you should as a minimum, move all the code you want to dynamically import into imports/.

Most atmosphere packages do not support dynamic importing - those will always be eagerly loaded. For more infomation, take a look at this issue.

2 Likes

I just tested this out, and turns out most of my biggest offenders do not support dynamic importing. Is there no workaround for these packages?

You could git clone the packages into a local packages directory and make the changes to the various package.js files. Then, export METEOR_PACKAGE_DIRS=your-local-package-dir and build with the updated packages.

(I’ve not tried this, but it should work).

2 Likes

Or you can just make local packages directory in the project, make the changes and bump the version. While at it you can also submit a PR to the original package. :wink:
Then when you do meteor update and meteor list you should see which packages are build from local sources.

2 Likes

You can - but if you want to use the packages in other apps, it’s easier and cleaner to have a shared directory.

1 Like

For my use case, since I’ve got only one Meteor app, I can use my apps packages directory without issues. I wasn’t expecting the conversion to be too simple, I’ll check if it works for the packages I’m using. Thanks for the help!

2 Likes

So I’ve hit a bit of a roadblock. I’m not sure I’m doing this right.

I converted the api.addFiles in a package to add {lazy: true}, and verified that it doesn’t get included in the initial client bundle post that.

But when I try to dynamically import it

import("meteor/asad:package-name").then(function (a) {
  console.log(a);
});

it just logs "{"default":{}}" to the console. What did I do wrong?

And while we’re at it, how would I go about lazy loading dependencies too? I’m trying to create a dynamically importable package for Medium Editor, and a plugin for it has heavy dependencies that I’d like to dynamically import as well.

It seems only the file defined as api.mainModule gets loaded when I do the above import, api.addFiles files are ignored according to the websocket frames.

EDIT:
I assume this is because it expects an export. When I do do that, I get an unexpected token export error message in the browser console. Workaround by attaching the object to window from the dynamically imported file works.