A merchant sends you an error: Cannot read properties of undefined. The stack points into a compressed JavaScript bundle. You know something failed, but finding the responsible code is still work.

A source map can connect that generated location to the original file and line. The useful part is not merely having a .map file. It is connecting the captured error, the deployed asset and the matching build artifact.

Keep the build together

This fictional sequence shows the difference:

Captured stack:  cart.min.js:1:8452
Deployed build:  storefront@2.18.4
Usable mapping:  cart.ts:184
Observed code:  selectedRate.handle

The original line suggests that selectedRate may be missing. It does not explain why the lookup failed. You still need the release, affected environment and action before the error to choose a reproduction case.

A source map from a different build can point somewhere misleading. Rebuilding after preparing the map can also change the asset. Treat the release identifier, generated files and source maps as one build throughout the workflow.

Follow one release through upload and publication

Dozenfold’s source-map setup guide documents the exact commands and permissions. The recurring workflow is:

  1. Prepare the built files. Use the source-map injection step on the final build output so the assets and maps have matching debug identifiers.
  2. Upload the corresponding maps. Associate them with the immutable release using a scoped source-map token in your build environment.
  3. Publish that prepared build. Avoid rebuilding between injection, upload and deployment.
  4. Verify the served asset. Use the verification step against the published asset, including its CDN response, rather than relying on a successful upload alone.

CI is the practical route for recurring deployments. A Shop Owner can also use the bounded manual upload flow for one Shopify build. Keep credentials in the build environment; a private upload token should never become part of storefront JavaScript.

Read the result in the issue

Open the developer section for a captured occurrence. When the stack and map can be resolved, Dozenfold shows the original frame and a limited source excerpt. It does not offer complete source files for browsing in the merchant interface.

If mapping is unavailable, investigate the captured stack and check these boundaries:

  • Did the deployed asset come from the build you uploaded?
  • Is the release identity correct?
  • Does the map contain the information needed to resolve this frame?
  • Is the browser providing a usable stack for this error?

A successful map upload cannot create a stack that the browser never supplied. Missing mapping should remain visible while the rest of the issue’s evidence stays useful.

Hand off the code with its context

The Developer brief keeps the technical fingerprint, source context, environment and observed journey together. Copy it into your development workflow or give it to a coding assistant alongside your repository.

Keep the proposed diagnosis distinct from the captured evidence. A missing value at one line is a lead; testing the actual path is how you establish a fix. After deploying, return to the issue and watch for recurrence under relevant traffic.

Explore the source-context example in the product tour. All figures and source snippets in that tour are illustrative, so you can inspect the workflow before connecting a store.