[NO-CDX] Bundle required packages

[esezen]

No description provided.

[constructor-claude-bedrock]

Code Review

This PR removes the external exclusion for @constructor-io/constructorio-id and crc-32 from build-esm.js, causing them to be bundled into the lib/esm/constructorio.js module entry point rather than resolved at runtime by the consumer.

Inline comments: 2 discussions added

Overall Assessment: ⚠️ Needs Work

[constructor-claude-bedrock]

Important Issue: Removing the external option causes @constructor-io/constructorio-id and crc-32 to be bundled directly into lib/esm/constructorio.js, which is the "module" entry point consumed by downstream bundlers (webpack, rollup, vite, etc.).

This has two concrete risks:

1. Duplicate code / broken singleton semantics: If a consumer (or another package) also depends on @constructor-io/constructorio-id, their bundler will now include two separate copies — one inside this bundle, one resolved normally. This is particularly problematic for @constructor-io/constructorio-id, which likely maintains internal singleton state (session/visitor IDs). Two copies means two independent instances, which can corrupt ID tracking.

2. Bundle size increase: Both packages are dependencies in package.json, so consumers already receive them. Bundling them into lib/esm/ means consuming applications carry the bytes twice.

The dist/esm/ build (bundle-esm.js) is the appropriate place to bundle everything, as it targets standalone/CDN usage where the consumer has no package manager. The lib/esm/ build targets module-aware bundlers that should resolve dependencies themselves.

Recommended fix: Restore the external array, or if intentional, document the reasoning clearly and consider whether these packages should be moved to peerDependencies to signal that the consumer must provide them (which would be inconsistent with the current approach). At minimum, add a comment explaining why bundling into lib/esm/ is desired here.

[constructor-claude-bedrock]

Suggestion: The PR has no description, which makes it hard to understand the intent. The title says "Bundle required packages" but there's no explanation of what problem this solves (e.g., were consumers seeing missing-module errors? Was constructorio-id not being resolved correctly in some environments?).

Please add a PR description explaining:

• What problem was observed
• Why bundling into lib/esm/ (rather than only dist/esm/) solves it
• Any tradeoffs acknowledged (duplicate instances, bundle size)

This context is important for future maintainers who encounter issues tracing back to this change.

[Copilot]

Pull request overview

This PR updates the ESM build step to produce a more self-contained lib/esm/constructorio.js by no longer treating @constructor-io/constructorio-id and crc-32 as external dependencies during the esbuild run.

Changes:

• Removed the external configuration from scripts/build-esm.js, allowing esbuild to bundle @constructor-io/constructorio-id and crc-32 into the generated ESM output.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.