From 947b06dd13ef576bd90382f583f0b227a0c9a2df Mon Sep 17 00:00:00 2001 From: Hans Ott Date: Wed, 20 Nov 2024 16:13:18 +0100 Subject: [PATCH] Replace with Zen --- docs/esbuild.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/esbuild.md b/docs/esbuild.md index 555ccf2f..df7870b1 100644 --- a/docs/esbuild.md +++ b/docs/esbuild.md @@ -6,7 +6,7 @@ Zen works by intercepting `require()` calls that a Node.js application makes whe Bundlers crawl all of the `require()` calls that an application makes to files on disk. It replaces the `require()` calls with custom code and combines all the resulting JavaScript into one "bundled" file. When a built-in module is loaded, such as `require('fs')`, that call can then remain the same in the resulting bundle. -Zen stops working at this point. They can continue to intercept the calls for built-in modules but don't intercept calls to third party libraries. This means that when you bundle a Zen app with a bundler it is likely to capture information about disk access (through `fs`) and outbound HTTP requests (through `http`), but omit calls to third party libraries. +Zen stops working at this point. Zen can continue to intercept the calls for built-in modules but don't intercept calls to third party libraries. This means that when you bundle a Zen app with a bundler Zen is likely to capture information about disk access (through `fs`) and outbound HTTP requests (through `http`), but omit calls to third party libraries. The solution is to treat all third party modules that Zen needs to instrument as being "external" to the bundler. With this setting the instrumented modules remain on disk and continue to be loaded with `require()` while the non-instrumented modules are bundled.