An import map gives the browser rules for resolving module specifiers in module scripts.
Make this comfortable
HTML import maps: resolve a module name to a controlled local file
Why this choice matters
A case dashboard imports a small local chart module by a stable name. The map keeps that name independent from the file path, but it does not install packages, bundle dependencies, or verify the chart's output. Serve the referenced file with an appropriate JavaScript media type and place the map before a module that relies on its rule. A build tool may already rewrite imports, so use this mechanism when native browser resolution is a deliberate deployment choice.
<script type="importmap">
{
"imports": {
"case-chart": "/assets/case-chart-v47.mjs"
}
}
</script>
<script type="module">
import { renderCaseChart } from "case-chart";
renderCaseChart(document.querySelector("#case-chart"));
</script>
<div id="case-chart"><p>Case chart loads when scripting is available.</p></div>What it does not do
The local module must exist and export renderCaseChart. If the import or render fails, users still need an accessible text summary of the underlying case data; the placeholder alone is not such a summary.
Cost and operational limits
The map is small, but the imported module and its graph add network and execution cost. Measure them separately and avoid a chart for data that a short table can present more clearly.
Common Mistakes
- Do not place a required import map after modules resolve.
- Do not assume a mapped file exists because the JSON parses.
- Do not make the chart the only representation of case data.
Connected lessons
html
advanced