# `MishkaCmsCore.Test.JsAssets`
[🔗](https://github.com/mishka-group/mishka_cms_core/blob/v0.0.3/lib/mishka_cms_core/test/js_assets.ex#L5)

Provisions the `node_modules` tree esbuild resolves runtime JS bundles against.

`MishkaCmsCore.Runtime.Compilers.JavaScriptCompiler` emits an entry file that does
`import { Socket } from "phoenix"`, and esbuild resolves those bare specifiers through `NODE_PATH`
— `config/test.exs` points it at `priv/static/temp/js_assets/node_modules`. A host fills that
directory as part of its asset build (the CMS keeps checked-in copies); running on our own, nothing
does, and every JS compilation fails with `Could not resolve "phoenix"`.

So the harness fills it from `deps/`, where each of these packages already ships a prebuilt CommonJS
bundle — the same code the CMS vendored, read from the version this suite actually depends on rather
than a copy that can drift. Only the packages the generated entry file imports are provisioned;
`phoenix-colocated` is not among them because the compiler writes that one itself.

Called once at boot by `MishkaCmsCore.Test.Boot` (its `js_assets:` option), before any test
compiles JS. The directory is the one the suite's esbuild `NODE_PATH` names: core's own by default,
an extension's under its own `priv/static/temp/js_assets/node_modules`.

# `install!`

```elixir
@spec install!(Path.t()) :: :ok
```

Writes a minimal package directory for each entry in `@packages` into `node_modules`, overwriting
what is there. The bundles are read from the `deps/` of the project being tested.

Raises when a dep is missing its prebuilt bundle: that means the dependency changed shape, and a
silent skip would resurface as an esbuild resolution error much further from the cause.

---

*Consult [api-reference.md](api-reference.md) for complete listing*