-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue with instanceof
operator
#3333
Comments
I suspect that #475 is irrelevant because that issue is about something cosmetic that doesn't result in a behavior change. I don't have time to investigate your code right now but generally when this happens it's not a problem with esbuild. You need to figure out why your code is including multiple copies of the same package. Sometimes it's because your code is encountering npm's dual package hazard (happens when some code imports the ESM version and other code imports the CommonJS version of a package) and sometimes it's because there are multiple different versions of the package on the file system after an npm install. You can use https://esbuild.github.io/api/#analyze to debug this. |
Let me confirm what evan said based on your reproduction.
You have 2 packages and both of them are importing packages/handlers-lib/src/helpers/response/map-error-to-response.ts
import { ZodError } from 'zod';
packages/lambda/src/validators/test.validator.ts
import { z } from 'zod'; And both of them are built into CJS format in their build command (and in vitest environment) with all their dependencies bundled in. esbuild's resolver is depending on the actual import kind (import or require) in the source code, now these TypeScript sources are using Let's see what happens:
That's why you have 2 versions of ZodError. Now let's try excluing
Wrong again! Why? Because you now have 2 different import kinds (require in handlers-lib's output, import in lambda's source code). And they can be resolved to different files in the zod package. Okay now let's try again with a different approach -- Exclude everything during development, but bundle them in at the final step, which means appending Now you will get a clean lambda/build/index.js, and all it's dependencies only has one copy hand one import kind: // handlers-lib/build/index.js
var import_zod = require("zod");
// lambda/build/index.js
var import_handlers_lib = require("handlers-lib");
var import_zod = require("zod"); // looks ok! You will build the final lambda js with this command: esbuild packages/lambda/build/index.js --bundle --platform=node --outfile=bundle.js |
@evanw @hyrious Thank you for your responses! They provided me with significant insights that led me to discover an alternative solution. Instead of bundling the base package and externally exposing the bundled |
Description:
I am encountering an issue within my monorepo setup where I have a base library package that is imported into other packages. This base package contains error handling code that utilizes the
instanceof
operator, which appears to not work as expected. I am also using thezod
library, which is imported into each individual package. The problematic code is located within the base package:Despite throwing the ZodError, the
instanceof
check always returnsfalse
.Upon inspecting the bundled code, I noticed that esbuild is generating two distinct ZodError classes, namely ZodError and ZodError2. I suspect that this issue might be related to #475 . My guess is that one error class is generated within the base package, while the other one is generated from the package which imports the base package. Consequently, one package throws a ZodError2, while the base package performs an
instanceof
check against ZodError.This issue exists both in commonjs and esm formats.
Expected Behavior:
I expect that the
instanceof
check for ZodError should return true when ZodError is thrown, even in cases where theinstanceof
check is executed within the base package, while the actual error is thrown in a different package that imports the base one.Steps to Reproduce:
packages/lambda/build/index.js
for existence of two ZodError classes (in my case it was ZodError and ZodError2)The text was updated successfully, but these errors were encountered: