From 04d411a23948abc7dbedd61580807b374844e1ff Mon Sep 17 00:00:00 2001
From: willem-delbare <20814660+willem-delbare@users.noreply.github.com>
Date: Thu, 28 Nov 2024 10:28:21 +0100
Subject: [PATCH] Update docs/esbuild.md

---
 docs/esbuild.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/esbuild.md b/docs/esbuild.md
index 95e6a11b..dd8016b4 100644
--- a/docs/esbuild.md
+++ b/docs/esbuild.md
@@ -8,7 +8,7 @@ Zen works by intercepting `require()` calls that a Node.js application makes whe
 
 Bundlers like esbuild 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. 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.
+Zen can continue to intercept the calls for built-in modules but cannot intercept calls to third party libraries under those conditions. 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.