[Feature Request] Lazily load webpack

[arlyon]

Hi

I would like to strip webpack from my bundle for container efficiency reasons but can't because webpack is loaded eagerly. By lazily loading workflow/bundler in index and in worker you can get away with deleting webpack and friends from the bundle (in my case the docker container)

I have achieved it by applying this patch (on the build outputs) but I am sure doing a similar thing would be fairly easy on the typescript side. Note I have just removed the default interceptor warning altogether.

diff --git a/lib/index.js b/lib/index.js
index ac5a7f9594321f75f52ac0641621d91c02c9ba8c..3aaa482c51d04627d9d7a2b96755f721ec2b5949 100644
--- a/lib/index.js
+++ b/lib/index.js
@@ -52,8 +52,7 @@ Object.defineProperty(exports, "defaultPayloadConverter", { enumerable: true, ge
 Object.defineProperty(exports, "Worker", { enumerable: true, get: function () { return worker_1.Worker; } });
 var replay_1 = require("./replay");
 Object.defineProperty(exports, "ReplayError", { enumerable: true, get: function () { return replay_1.ReplayError; } });
-var bundler_1 = require("./workflow/bundler");
-Object.defineProperty(exports, "bundleWorkflowCode", { enumerable: true, get: function () { return bundler_1.bundleWorkflowCode; } });
+Object.defineProperty(exports, "bundleWorkflowCode", { enumerable: true, get: function () { return require("./workflow/bundler").bundleWorkflowCode; } });
 /* eslint-disable deprecation/deprecation */
 // Anything below this line is deprecated
 var activity_log_interceptor_1 = require("./activity-log-interceptor");
diff --git a/lib/worker.js b/lib/worker.js
index e8cf98a86e9e1045af378319f6242f1ba66a3194..d4fc8999e3ef50d64c3d87338d930f3a0e0c28e8 100644
--- a/lib/worker.js
+++ b/lib/worker.js
@@ -57,7 +57,6 @@ const rxutils_1 = require("./rxutils");
 const utils_1 = require("./utils");
 const worker_options_1 = require("./worker-options");
 const workflow_codec_runner_1 = require("./workflow-codec-runner");
-const bundler_1 = require("./workflow/bundler");
 const reusable_vm_1 = require("./workflow/reusable-vm");
 const threaded_vm_1 = require("./workflow/threaded-vm");
 const vm_1 = require("./workflow/vm");
@@ -317,12 +316,6 @@ class Worker {
                 logger.warn('Ignoring WorkerOptions.bundlerOptions because WorkerOptions.workflowBundle is set');
             }
             const modules = new Set(compiledOptions.interceptors.workflowModules);
-            // Warn if user tries to customize the default set of workflow interceptor modules
-            if (modules &&
-                new Set([...modules, ...bundler_1.defaultWorkflowInterceptorModules]).size !== bundler_1.defaultWorkflowInterceptorModules.length) {
-                logger.warn('Ignoring WorkerOptions.interceptors.workflowModules because WorkerOptions.workflowBundle is set.\n' +
-                    'To use workflow interceptors with a workflowBundle, pass them in the call to bundleWorkflowCode.');
-            }
             if ((0, worker_options_1.isCodeBundleOption)(compiledOptions.workflowBundle)) {
                 return parseWorkflowCode(compiledOptions.workflowBundle.code);
             }
@@ -335,6 +328,7 @@ class Worker {
             }
         }
         else if (compiledOptions.workflowsPath) {
+            const bundler_1 = require("./workflow/bundler");
             const bundler = new bundler_1.WorkflowCodeBundler({
                 logger,
                 workflowsPath: compiledOptions.workflowsPath,

[mjameswh]

Yeah, making this dependency optional is definitely in my plans.

The approach you propose is a much lighter alternative to what was discussed in #933. I like it.

I don't think that the modification you did in index.js can be done in pure TS (nor would it be compatible with ESM once we get there), as you technically can't export a property getter. It would however be possible to export a stub bundleWorkflowCode function that internally does a dynamic import to the actual bundleWorkflowCode implementation, which could then live in a different, optional package.

[mjameswh]

Regarding the user land workaround you described, you have not mentioned how you prevent the webpack package from being installed in the node_modules directory (or from your generated worker bundle, if applicable), to start with, which is required if your goal is to save disk space.

I'm just curious how you did this. Are you using another bundling tool to bundle your worker code? Or are you doing this by using some form of dependency tree modifiers specific to either NPM/PNPM/Yarn (e.g. overrides, resolutions, readPackage, etc)?

[arlyon]

Hey!

Yes, the onus is still up to the user to make sure it doesn't get shipped, but this change makes it possible at least even if nodejs lacks the nuance to make it automatic.

We ship docker containers so I went down the rabbit hole to optimise them for size / layers. The basic process is to figure out which are external dependencies (things that cannot be bundled) and copy only those (and their transitive dependencies) from your node modules into the final container. A side effect is that you might end up with the same module in your bundle and in your node_modules since your externals might need it. You could probably get around it but it's not worth my time.

https://gist.github.com/arlyon/c48c39b61c518e03da4e13b3086b37e5

Short explainer:

• use tsup
• force webpack to be an external dependency
• parse the tsup metafile to get the internal / external dependencies
• parse pnpm list to traverse dependencies of external dependencies and get the transitive closure (since an external dependency can only look for its dependencies in node_modules, not your bundle)
• filter out packages you know you don't need at runtime
  • I looked at overriding those deps with an empty package in package.json but we'd have to apply that only to the builds inside the container (which felt a little black-magic-y) since they are still needed during dev runtime.

I realise this is maybe overkill but you end up with very cacheable layers and very fast / light builds. We currently ship:

• total container size: 335MB
• OS: ~130MB
  • node: 110MB
• external deps layer: 145MB
  • temporalio: 100MB
  • otel: 27MB
• code layer: 44MB
  • worker bundle: 5MB
  • worker source map: 24MB
  • workflow bundle: 12MB (with sourcemaps embedded)

[mjameswh]

Nice!

You should be able to strip an extra 60 MB very easily by removing native library files you don't need from the node_modules/@temporalio/core-bridge/releases directory. Just keep the one for your target platform.