Check source maps for scripts deployed on WordPress

Define the need to distribute sources

A source map links a transformed JavaScript file to the files from which it was built. It helps explain an error in browser tools or a diagnostic system. On WordPress, it may accompany a theme script, a plugin script, or project-specific code. Before removing it, identify its owner and the diagnostic use that depends on its availability.

The policy may allow public maps for a freely distributed component, reserve the project’s maps for a private error platform, or keep only the files needed by the browser. Have the code owner clarify this policy. The JavaScript file delivered to the browser remains accessible through the route used. Controlling maps therefore concerns their additional content, storage location, and the references that make them discoverable.

Start with an identified script and version. Searching for all files with a map extension on the server is not enough to determine which are published. Conversely, some maps may be embedded in the script or served from another host. The check must compare the package, HTTP response, and browser observations.

Connect the page to the script and its package

On a representative copy, open a page that loads the component concerned and record the script address in the Network panel. Note the path, version name, and response type. An optimization tool may combine or rewrite scripts, producing a different file from the original package. In that case, identify the component performing this transformation and when it generates the resource.

Match the public URL to the file in the approved artifact. Check the deployed version and pipeline reference. A name containing a hash helps distinguish releases, but must be confirmed by the build manifest. With multiple frontends, ask which package supplies the response. Keep the root and version number in the private record to avoid comparing with a different local rebuild.

If the script belongs to a third-party publisher, consult its distribution policy and diagnostic documentation. Manually deleting files in the plugin folder may be undone by the next update. Have distribution addressed at the level of the mechanism that actually publishes the component’s files.

Find the map reference in browser tools

In Chrome DevTools, use the Sources panel and developer resources to see whether a map is associated with the script. Source map support settings affect how maps load in the tools. Record the advertised address, loading result, and any error message. A map absent from the panel may be unavailable, incorrectly referenced, or simply not requested in this context. Compare against the script response and browser settings.

Inspect the sourceMappingURL reference in the file and the SourceMap header when present. A reference may be relative to the file, absolute, or embedded as data. The header may take the precedence described in the documentation over a file annotation. Ask the maintainer to confirm address resolution when several transformations are involved. Avoid automatically following a reference to an external host outside the authorized scope.

Record the relationship between the page, delivered script, and its map. A screenshot of the tools must be redacted if it displays internal paths or project names. Demonstration messages used as evidence must avoid customer data.

Record the headers of the served resource

For a public script within scope, the following command displays the headers of a normal request and discards the body in a Unix terminal. Replace the example path with the one recorded in the browser. It does not follow redirects. Check the status, content type, and headers before attributing a reference to the expected script. A refusal page or frontend response may contain other information.

If the map is referenced on another authorized route, record its status and type without launching a program or executing its content. A map is a data document to examine, not a script to run to verify its role. Use private storage for any necessary copy. References may contain an internal path or signed URL, to be protected according to their use.

Compare the record against the response actually loaded by the browser. A cached variant or network transformation may present another reference. Keep dated observations for both the script and map. Deleting from the package does not prove that every published copy has become inaccessible.

The -q option must remain the first argument to ignore implicit curlrc options. Use the intended curl executable and retain applicable proxy settings. An incomplete transfer or refusal status does not prove the absence of a map. In the browser, check Settings > Preferences > Sources > JavaScript source maps, then the corresponding resource in Developer Resources. Enabling this must lead to examination only of addresses assigned to the scope.

curl -q --silent --show-error --max-time 15 --dump-header - \
  --output /dev/null 'https://recette.example/assets/application.js'

Examine the map’s additional content

On the private copy, have the fields describing sources, names, and any embedded content examined. A map may contain original text, build paths, or module names. Another may contain only mappings and source references. In a local JSON editor, examine sources for paths, sourcesContent for embedded text, and sourceRoot for any source root. Also compare exposed names against project policy; a path list may be enough to reveal internal structure. The exact content depends on the generation mode. An empty map file or a file that does not match the script cannot be used to assess the current release.

Record the categories of information the owner wants to keep private. For example, internal paths, project code not intended for distribution, or service references may warrant changing the publishing pipeline. If you discover a value that is a usable secret, have its exposure and rotation handled by the service owner. Simply removing the map does not make that secret confidential again in copies already received.

Also check the published JavaScript file and other artifacts in the same package according to the analysis need. A value may have been embedded in the final code independently of the map. The decision about sources must be based on the entire affected package, with an explicit scope.

Choose publication suited to diagnostics

For a project component, ask the build owner how maps are generated and delivered. Build tools may offer variants that include sources, omit their content, or produce an external map without a reference in the file. With webpack, hidden-source-map removes the script reference but still produces an external map; nosources-source-map removes embedded source text but can still reveal file names and structure. These choices are not access control. The mode must be chosen for the actual use and tested on the production artifact, because staging rules may differ.

If diagnostics use a private platform, plan to send maps to the authorized service with the corresponding version and remove them from the public package according to policy. A map left on the server at a known URL remains retrievable if the server permits it, even when the script no longer advertises it. Confirm permissions and the retention lifecycle of private storage.

If maps must remain public, examine their content and have distribution approved. The need to simplify support for an open component may justify this choice. The record must then specify the owner, published files, and the check ensuring no build data unintended for this channel is included.

Prepare a reversible release

Keep the current package, script and map manifest, server rules, and build configuration. Identify which files change and which tools republish them. On a copy, produce the new package using the usual method. Check references, file names, and public locations. Excluding a file may require cleaning the destination if deployment only adds new artifacts.

Prepare rollback for the package and private diagnostics. A release may continue working in the browser while the error-tracking system can no longer find the right map. Define a demonstration test that checks both needs without creating a real incident. Keep the version references that associate an error with its release.

If the server must refuse certain maps, restrict the rule to approved paths. A blanket ban on an extension may affect a third-party component or another file use. Have the server owner review the scope and check the response received at the exact URL. Access rules and package construction require complementary validation.

Check the browser and old addresses

After the staging release, load a fresh page that uses the script. Check its status, expected content, and demonstration functions. Consult developer tools to see whether a map is still requested and whether the result matches policy. A missing map message may be acceptable under an intended publication mode, but the maintainer must understand and document it.

Then request the known old map addresses that are within scope. Check whether the server or frontend still serves them and whether they were supposed to be removed. A new versioned artifact does not automatically delete files from previous versions. Request a targeted purge of public copies when the plan requires it, then check the response at the same URL. A different URL does not demonstrate removal of the old one.

For the private diagnostic platform, confirm that the demonstration version finds the appropriate map and access is limited to intended roles. Keep redacted evidence of the match without exposing sources in a more widely shared ticket.

Handle a reference that returns after optimization

If a map or its reference reappears after a cache or optimization change, identify the component that recreated the file. A tool may rebuild a bundle from theme sources and publish its own resources. Correct its generation configuration or output channel according to its documentation. Repeated manual deletion may only hide the problem until the next rebuild.

Compare the file served before and after this step using its version identifier. If the reference is in a header added by the frontend, have that layer corrected instead of the theme code. If it comes from an annotation in the script, confirm which package version produced it. Updating a map without its corresponding script may make diagnostics misleading, even if both files respond correctly.

Keep observations from each step. The record must show which operation creates the reference and which mechanism controls its distribution. This makes it possible to choose a lasting change and test its persistence after the next normal release.

Restore the expected function if a regression occurs

If the new package breaks site behavior, restore the approved package through the deployment mechanism. Check scripts, business functions, and diagnostic references after rollback. Removing a map should not be used to hide an error in the final script. Compare the regression against build changes and the files actually delivered.

If only private error reading is broken, check the release identifier and the match between the map and transformed file. Restore diagnostics according to the plan without automatically republishing all sources. The owner may choose a temporary solution limited to the private service while reviewing the pipeline. Keep the rollback time and evidence from the demonstration scenario.

For a sensitive value already distributed, follow the planned incident handling even if the old URLs now return a refusal. Copies may have been received before the correction. Public file deletion and secret handling must therefore be tracked separately with the relevant owners.

Hand over the policy for each package and version

The final record must identify the script, map, generation mechanism, and distribution channel. Add the approved policy, references to current files, and the result for known old addresses. If the check covers only one component, state that. Examining a theme’s map does not validate maps from other plugins. The retained information must allow the finding to be reproduced with the same version.

Chrome DevTools and curl can provide the observations described without an additional subscription. Build tools and private diagnostic platforms have their own terms, to be checked for the service actually used. The method does not require changing tools when the project already has a workflow capable of controlling artifacts.

Keep primary sources and the configuration version internally. Schedule this check when the pipeline, an optimization tool, or a diagnostic provider changes. The next person can check package distribution and diagnostic capability from an identified state.

The WordPress Workshop.

Configuration example for a project already built with Vite

This addition applies only to project code whose Vite build you control, not to third-party plugin files. In the existing configuration file, keep plugins, entry points, and other options, then set build.sourcemap to false. Here is a minimal standalone example; do not replace the entire real configuration with it.

Rebuild into a clean output directory using the project’s usual command. Inspect the package: build plugins may produce their own maps despite this option. Also compare served scripts, their annotations, and HTTP headers. Publishing the new folder without cleaning an old destination may leave old maps accessible; their removal must be included in deployment.

If error tracking requires private maps, hidden produces files without an annotation in the bundle: you still need to transfer them to the private service and exclude them from the public package. This is not access protection. Keep the previous approved package to restore functional behavior without automatically republishing maps forbidden by policy.

import { defineConfig } from 'vite';

export default defineConfig({
  build: {
    sourcemap: false,
  },
});