marko 5.21.8 → 5.21.10

package/docs/compiler.md

@@ -1,27 +1,46 @@
 # Compiler
 
-> **Note:**
-> The compiler is an advanced API intended for integrating with build tools (webpack, rollup, etc.) and experimenting with new language features in userland. It's best to use existing official plugins and the standard tag library when possible.
+> **Warning**:
+> The compiler API and hooks are not terribly stable. They’re intended for advanced integrations or userland experimentation with new language features.
+>
+> Prefer existing official plugins and the standard tag library when possible.
 
 ## Compile API
 
+> **Warning**:
+> The Compile API is intended for advanced integration with build tools, like Webpack and Rollup. Unless you’re doing that, you probably instead want [`build`/`serve` in the Marko CLI](https://github.com/marko-js/cli#readme), or one of [Marko’s bundler integrations](https://markojs.com/docs/bundler-integrations-overview/).
+
 ### Compile Functions
 
-The compile functions take an input Marko template [`CompileOptions`](#options)and produce a `CompileResult` containing the executable JavaScript:
+Compile functions take two arguments:
+
+1. A source Marko template
+2. [`CompileOptions`](#options)
+
+Then, they return a `CompileResult`:
 
 ```ts
 type CompileResult = {
-  meta: Record<string, unknown>; // Meta data gathered while compiling
-  map?: SourceMap; // A sourcemap
-  code: string; // The translated code
+  code: string;
+  map?: SourceMap;
+  meta: Record<string, unknown>;
 };
 ```
 
-#### `compiler.compileFile(filename: string, options?: CompileOptions): Promise<CompileResult>`
+- `code`: The compiled output of executable JavaScript code.
+- `map`: [A source map, used for debugging.](https://firefox-source-docs.mozilla.org/devtools-user/debugger/how_to/use_a_source_map/index.html)
+- `meta`: Metadata gathered while compiling — nothing terribly useful, probably going to get deprecated.
+  - Data about child dependencies. Was useful back when it was primarily the bundlers that handled tree-shaking out server components. Now that happens in the compiler, so we don’t use this anymore and therefore might become inaccurate in the future.
+  - A list of `watchFiles`: files that were used to compile the template (e.g. `marko.json`). Used to tell bundlers which files should be watched in dev mode.
 
-#### `compiler.compileFileSync(filename: string, options?: CompileOptions): CompileResult`
+#### `compileFile()` and `compileFileSync`
 
-`compileFile` and `compileFileSync` load the source template at `filename` from disk and translate it into JavaScript.
+```ts
+compiler.compileFile(filename: string, options?: CompileOptions): Promise<CompileResult>
+compiler.compileFileSync(filename: string, options?: CompileOptions): CompileResult
+```
+
+`compileFile` and `compileFileSync` load `filename` from disk to use as a source template, then translate it into JavaScript.
 
 ```js
 import * as compiler from "@marko/compiler";
@@ -34,11 +53,16 @@ const syncResult = compiler.compileFileSync("./src/index.marko", {
 });
 ```
 
-#### `compiler.compile(src: string, filename: string, options?: CompileOptions): Promise<CompileResult>`
+#### `compile()` and `compileSync()`
 
-#### `compiler.compileSync(src: string, filename: string, options?: CompileOptions): CompileResult`
+```ts
+compiler.compile(src: string, filename: string, options?: CompileOptions): Promise<CompileResult>
+compiler.compileSync(src: string, filename: string, options?: CompileOptions): CompileResult
+```
 
-`compile` and `compileSync` allow passing the source template as a string rather than loading from disk. The `filename` location is used for resolving taglibs and imports, but does not have to actually exist on disk.
+`compile` and `compileSync` accept source templates as a string, rather than loading from disk.
+
+The `filename` location is used for resolving taglibs and imports, but does not have to be an actually existing file. <!-- TODO: should it be renamed to baseFile or importBase or something? -->
 
 ```js
 import * as compiler from "@marko/compiler";
@@ -55,64 +79,79 @@ const syncResult = compiler.compileSync("<h1>Hello!</>", "./src/index.marko", {
 
 ### Options
 
-Configuration options may be passed when calling the above compile functions or the compiler may be configured globally, overriding the default compiler options:
+The compiler may be configured globally to change its default options:
 
 ```js
 import * as compiler from "@marko/compiler";
 compiler.configure({ output: "dom" });
 ```
 
+Or you can pass options objects when calling compile functions. Each property will override individual properties set by `configure()`:
+
+```js
+import * as compiler from "@marko/compiler";
+compiler.configure({
+  output: "dom",
+  sourceMaps: true
+});
+const result = compiler.compileFileSync("./example.marko", {
+  output: "html"
+});
+```
+
+In the above example, `result` would be compiled with the options of `{ output: "html", sourceMaps: true }`.
+
 #### `output`
 
 Type: `string`<br>
 Default: `"html"`
 
-- `"html"` - compiles the template to JavaScript that generates HTML strings.
-- `"dom"` - compiles the template to JavaScript that generates DOM nodes.
-- `"hydrate"` - similar to DOM, but only includes the assets & components needed in the browser, assuming the page was rendered on the server.
-- `"migrate"` - only runs migrations (not transforms or translation) and returns the migrated template code.
-- `"source"` - parses Marko file without running any migrations / transforms. (useful with `ast: true`)
+- `"html"`: compiles templates to JavaScript that generates HTML strings for server HTTP responses, writing `.html` files, or maybe even constructing `Response`s in Web Workers.
+- `"dom"`: compiles templates to JavaScript that generates DOM nodes for client-side rendering in browsers.
+- `"hydrate"`: like `"dom"`, but only includes assets & components needed in-browser, assuming the page was rendered on the server.
+- `"migrate"`: only runs migrations (no transforms or translation) and returns the migrated template code.
+- `"source"`: parses templates without running any migrations or transforms. (Useful with `ast: true`)
 
-When using output `dom` or `hydrate`, you should also specify a [`resolveVirtualDependency`](#resolvevirtualdependency) function.
+> **Note**:
+> For `dom` or `hydrate` outputs, you should also specify a [`resolveVirtualDependency`](#resolvevirtualdependency) function.
 
 #### `code`
 
 Type: `boolean`<br>
-Default: true
+Default: `true`
 
-If set to false, Marko will not generate the compiled source code string.
+If `false`, will not generate or return the compiled `code` string.
 
 #### `ast`
 
 Type: `boolean`<br>
-Default: false
+Default: `false`
 
-Set to true to have the compiler provide the `ast` in it's output.
+If `true`, the compiler will provide the `ast` in its output.
 
 #### `stripTypes`
 
 Type: `boolean|undefined`<br>
-Default: undefined
+Default: `undefined`
 
-Remove all typescript types from the output when `true`.
-If the value is `undefined`, the default, the compiler will remove types if
-the `output` option is not `source` or `migrate`.
+If `true`, removes all TypeScript types from the output.
+If the value is `undefined` (the default), the compiler will remove types if the `output` option is not `source` or `migrate`.
 
-For example to run migrations _and_ strip types you can set both `output: "migrate"` and `stripTypes: true`.
+For example, to run migrations _and_ strip types, you can set both `output: "migrate"` and `stripTypes: true`.
 
 #### `runtimeId`
 
 Type: `string`<br>
-Default: undefined
+Default: `undefined`
 
-Optionally use to override the runtime id (used to differentiate multiple copies of Marko on the same page) passed to `marko/components.init(runtimeId)` when compiling in the `hydrate` output.
+Optionally use to override the runtime ID used to differentiate multiple copies of Marko on the same page, which is passed to `marko/components.init(runtimeId)` when compiling in the `hydrate` output.
 
 #### `writeVersionComment`
 
 Type: `boolean`<br>
 Default: `true`
 
-Whether the version should be written to the template as a comment e.g.
+Whether the Marko version should be written to the template in a comment, like so:
 
 ```js
 // Compiled using marko@x.x.x - DO NOT EDIT
@@ -123,7 +162,10 @@ Whether the version should be written to the template as a comment e.g.
 Type: `boolean`<br>
 Default: `false`
 
-Whether unrecognized tags should be silently ignored rather than throwing a compile error. The the ignored tag will be output as a native element. Some test setups use this alongside `@marko/compiler/taglib`'s `excludeDir` and `excludePackage` to simulate "shallow" rendering.
+Whether unrecognized tags should be silently ignored or throw a compile error. Ignored tags will be output as native elements.
+
+> **ProTip**:
+> Some test setups use this alongside `@marko/compiler/taglib`'s `excludeDir` and `excludePackage` to simulate "shallow" rendering.
 
 #### `sourceMaps`
 
@@ -155,14 +197,14 @@ Use a different file system object (eg. webpack's [CachedInputFileSystem](https:
 Type: `string` (`"esm"` or `"cjs"`)<br>
 Default: `"esm"`
 
-By default Marko outputs ES Modules, you can optionally specify commonjs.
+By default Marko outputs ES Modules. You can optionally specify `"cjs"` for CommonJS/`require()`.
 
 #### `optimize`
 
 Type: `boolean`<br>
 Default: [environment based](https://github.com/marko-js/marko/blob/0f212897d2d3ec30b12c2f18ba950818bccb83b4/packages/compiler/src/babel-plugin/index.js#L277-L284) (`false` in development, `true` in production)
 
-Enables production mode optimizations
+Enables production mode optimizations.
 
 #### `resolveVirtualDependency`
 
@@ -181,7 +223,7 @@ Type:
 
 Default: `undefined`
 
-This option should be set when `dom` or `hydrate` output is specified. Since Marko templates can represent multiple output files (eg. JS renderer, CSS styles), we need to be able to treat a single source `.marko` file as multiple virtual files.
+This option should be set for `dom` or `hydrate` outputs. Since Marko templates can represent multiple output files (eg. JS renderer and CSS styles), a single source `.marko` file must be treated as potentially multiple virtual files.
 
 Different build tools have different mechanisms for handling virtual files. You should pass a function that returns a virtual path that can be handled by your build tool.
 
@@ -194,8 +236,7 @@ const virtualSources = new Map();
 function resolveVirtualDependency(filename, { virtualPath, code, map }) {
   const virtualFilename = `${filename}?virtual=${virtualPath}`;
 
-  // Add the virtual source to the lookup
-  // to be later accessed by the loader
+  // Add virtual source to the lookup to be later accessed by the loader
   virtualSources.set(virtualFilename, { code, map });
 
   // Generate the webpack path, from right to left...
@@ -233,14 +274,14 @@ export default function markoLoader(source) {
 
 #### `hydrateIncludeImports`
 
-This option is only used for `output: "hydrate"`. By default any `import`'s in server only files are not included in the hydrate output. However for some assets, for example stylesheets, it is useful to have them still be included in hydrate mode.
+This option is only used for `output: "hydrate"`. By default, `import`s in server-only files are not included in the hydrate output. However, for some assets, like stylesheets, it is useful to have them included in hydrate mode.
 
 The `hydrateIncludeImports` option allows you to provide a function which receives an import path, or a regexp to match against that path which tells Marko to include that import in the hydrate mode output.
 
-The default regexp includes a list of common known asset file extensions and is as follows:
+The default regexp includes a list of common known asset file extensions, and is as follows:
 
 ```js
-/\.(css|less|s[ac]ss|styl|png|jpe?g|gif|svg|ico|webp|avif|mp4|webm|ogg|mp3|wav|flac|aac|woff2?|eot|ttf|otf)$/;
+/\.(css|less|s[ac]ss|styl|png|jpe?g|gif|svg|ico|webp|avif|mp4|webm|ogg|mp3|wav|flac|aac|woff2?|eot|[ot]tf)$/;
 ```
 
 Looking at a partial Marko file such as:
@@ -253,19 +294,16 @@ import "./baz.wasm";
 <div/>
 ```
 
-In the `hydrate` output, with the default `hydrateIncludeImports`, would only cause `./foo.css` to be loaded in the browser.
+For `hydrate` output, with the default `hydrateIncludeImports`, would only cause `./foo.css` to be loaded in the browser.
 
 #### `cache`
 
-Type: typeof [`Map`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map) (specifically, `get` is required)<br>
+Type: typeof [`Map`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map) (specifically, `.get()` is required)<br>
 Default: `new Map()`
 
-Compiling a Marko template may require other (used) Marko templates to compile.
-To prevent compiling templates more than once, most of the compilation is cached.
+Compiling a Marko template may require other (used) Marko templates to compile. To prevent compiling templates more than once, most of the compilation is cached.
 
-The default cache strategy is to clear the cache on every macrotask.
-If the default cache is overwritten it is up to the user to determine when the
-cache is cleared.
+The default cache strategy is to clear the cache each macrotask. If the default cache is overwritten, it is up to the user to determine when the cache is cleared.
 
 #### `babelConfig`
 
@@ -285,22 +323,29 @@ Default: babel defaults, plus
 Type: `{ analyze: Visitor, transform:Visitor }`<br>
 Default: [autodiscovers](https://github.com/marko-js/marko/blob/0f212897d2d3ec30b12c2f18ba950818bccb83b4/packages/compiler/src/config.js#L46-L89) a translator package starting with `@marko/translator-` or `marko-translator-`
 
-The translator is a collection of transforms that translates the Marko AST into a valid JavaScript AST based on the `output` option. There is a default translator that ships with Marko, but this option may be used to switch to experimental translators for alternate runtimes.
+The translator is a collection of transforms that translates the Marko AST into a valid JavaScript AST based on the `output` option. There is a default translator in Marko, but this option may be used to switch to experimental translators for alternate runtimes.
 
-The translator is an object with two [Babel Visitors](https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/plugin-handbook.md#visitors): `analyze` and `transform`. The result of the analyze visitor is cached and may be requested by other templates. The transform visitor transforms the AST to it's final JavaScript AST.
+The translator is an object with `analyze` and `transform` [Babel Visitors](https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/plugin-handbook.md#visitors):
+
+- The result of the `analyze` visitor is cached and may be requested by other templates.
+- The `transform` visitor transforms the AST to its final JavaScript AST.
 
 See [`@marko/translator-default`](https://github.com/marko-js/marko/blob/11a10f82cdb5389880e6deca5f77d17727acb831/packages/translator-default/src/index.js) for a reference implementation.
 
 ## Hooks
 
-![Marko compiler hooks](./compiler-hooks.png)
+> **Note**:
+> These compiler hooks aren’t terribly stable either. Using hooks for one-time migrations, like a codemod, is the best-supported way to use the compiler hooks, since you won’t have to worry about the code changing underneath you in the future.
+
+![1. Parse (angle bracket source code) 2. Migrate (old Marko to new Marko) 3. Transform (objects to different objects) 4. Translate (Marko to JavaScript.)](./compiler-hooks.png)
 
-The Marko compiler runs through a series of stages to produce the final JavaScript output.
-These stages are intended for different aspects of processing the template and can be hooked into using [`marko.json`](./marko-json.md) configuration.
+The Marko compiler runs a series of stages to produce its final JavaScript output. These stages handle different steps of template processing, and can be tweaked, extended, and hooked into with [`marko.json` configuration files](./marko-json.md).
 
-All compiler hooks must export a visitor which will receive a [babel NodePath](https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/plugin-handbook.md#paths) with a `MarkoTag` node.
+- All compiler hooks must have a default export of a [Babel-style visitor function](https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/plugin-handbook.md#toc-visitors), which will receive a [babel `NodePath`](https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/plugin-handbook.md#paths) with a `MarkoTag` node.
 
-The hook will also receive a `types` object that matches the [@babel/types](https://babeljs.io/docs/en/babel-types) API extended with the [Marko AST types](#marko-ast). You can also get a reference to this by importing `{ types }` from the `@marko/compiler` module.
+- Hooks will also receive a `types` object that matches the [`@babel/types`](https://babeljs.io/docs/en/babel-types) API extended with the [Marko AST types](#marko-ast). (You may also reference the types by importing `{ types } from "@marko/compiler"`.)
+
+- Hooks may alternatively export an `enter` function (alias of `default`), and optionally an `exit` function. These map to [`@babel/traverse`’s `enter` and `exit` methods](https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/plugin-handbook.md#babel-traverse).
 
 Here is an example hook:
 
@@ -313,18 +358,15 @@ export default (tag, types) => {
 };
 ```
 
-Hooks can also export an `enter` (alias of `default`) and an `exit` function. These map to [@babel/traverse's](https://github.com/jamiebuilds/babel-handbook/blob/master/translations/en/plugin-handbook.md#babel-traverse) `enter` and `exit` methods.
-
 ### Parse
 
-The first step to Marko's compilation is to take the raw text of your Marko template and convert it into an "Abstract Syntax Tree".
-If you've not heard the term before, put simply it is just an object representation of your code.
+Marko compilation starts by converting the raw text of your Marko template into an [AST (Abstract Syntax Tree)](https://en.wikipedia.org/wiki/Abstract_syntax_tree) — an object representation of your code.
 
 ```marko
 <h1>Hello!</h1>
 ```
 
-Will roughly become
+…will roughly become:
 
 ```json
 {
@@ -345,63 +387,74 @@ Will roughly become
 }
 ```
 
-This might look a bit verbose, but we are aiming for completeness, not terseness in this output.
+This might look a bit verbose, but ASTs aim for completeness, not terseness.
+
+Marko parses in two steps to stay flexible with the ever-changing syntax of JavaScript:
+
+1. The first parsing pass happens in our [`htmljs-parser`](https://github.com/marko-js/htmljs-parser), which understands the HTML and HTML-like parts of your template.
 
-Marko takes a two-step parsing approach to remain flexible with the ever-changing syntax of JavaScript.
-The first pass of parsing happens in our very own [htmljs-parser](https://github.com/marko-js/htmljs-parser), which understands the HTML parts of your template.
+2. For JavaScript expressions, Marko defers to [`@babel/parser`](https://babeljs.io/docs/en/babel-parser). The resulting [Marko AST](#marko-ast) is a superset of what `@babel/parser` would return.
 
-For JavaScript expressions, Marko defers to [@babel/parser](https://babeljs.io/docs/en/babel-parser). The [Marko AST](#marko-ast) above is a superset of what would be returned from `@babel/parser`.
+To hook into the `parse` stage, use [the `parse` option in the `marko.json` file](https://markojs.com/docs/marko-json/#paths).
 
-To hook into the `parse` stage you can use the `parse` option in the `marko.json` file.
-The `parse` hook deviates from the rest of the compiler hooks in that it does not support the `enter` & `exit` API and you _must return_ a replacement AST node.
+> **Note**: The `parse` hook deviates from the other compiler hooks:
+>
+> - It does not support the `enter` & `exit` API.
+> - You _must return_ a replacement AST node.
 
 ### Migrate
 
-That's right, Marko has _ first-class_ support for migrations. This compiler hook allows for translating outdated APIs into their modern counterparts, leaving the rest of the compilation non the wiser.
-These migrations run automatically in the background and can be written to disk when users are ready by running the [`@marko/migrate` CLI command](https://github.com/marko-js/cli/blob/master/packages/migrate/README.md).
+That’s right, Marko has _first-class_ support for migrations. The **migration stage** can translate outdated APIs into modern counterparts, leaving the rest of the compilation none the wiser.
 
-To hook into the `migrate` stage you can use the `migrate` option in the `marko.json` file.
+Migrations run automatically in the background, and can be written to disk when users are ready by running the [`@marko/migrate` CLI command](https://github.com/marko-js/cli/blob/master/packages/migrate/README.md).
+
+To hook into the `migrate` stage, [use the `migrate` option in the `marko.json` file](https://markojs.com/docs/marko-json/#paths).
 
 > **Note:**
-> To make the compiler to stop at this point and output the migrated template rather than continuing on to produce the JavaScript output, pass `"migrate"` as the value for the `output` compilation option.
+> To make the compiler stop at this point and output the migrated template, rather than continuing to produce the JavaScript output, [set `output: "migrate"`](#output) in the [compilation options](#options).
 
 ### Transform
 
-The transform stage of the compiler is meant for userland transformations of Marko code, into other Marko code. Think of it like [babel.transform](https://babeljs.io/docs/en/babel-core#transform) for Marko templates.
+The **transform stage** is meant for userland transformations of Marko code into different Marko code. Think of it like [`babel.transform`](https://babeljs.io/docs/en/babel-core#transform) for Marko templates.
 At this stage, you are given a fully parsed and migrated AST to do what you will with.
 
-To hook into the `transform` stage you can use the `transform` option in the `marko.json` file.
+To hook into the `transform` stage, [use the `transform` option in the `marko.json` file](https://markojs.com/docs/marko-json/#paths).
 
 ### Analyze
 
-Next up is the analyze stage. This stage is intended to do non mutative analysis of the entire AST in a way that is cached in memory.
-Meta data should be stored on the `.extra` property of nodes and typically read in the [translate](#translate) stage, or using the child template analysis helpers.
+Next is the **analyze stage**, intended for non-mutative analysis of the entire AST in a way that can be cached in RAM.
+
+> **Note**:
+> “Non-mutative analysis” means that if you modify the AST during this stage, _you’ll probably regret it_ someday.
 
-To hook into the `analyze` stage you can use the `analyze` option in the `marko.json` file.
+Metadata should be stored on nodes’ `.extra` property. These `.extra` properties are typically read in [the translate stage](#translate), or when using the child template analysis helpers.
+
+To hook into the `analyze` stage, [use the `analyze` option in the `marko.json` file](https://markojs.com/docs/marko-json/#paths).
 
 ### Translate
 
-Finally, we have the translation stage. This stage is Marko's "Rosetta Stone" and is responsible for turning your beautiful Marko code into the optimized JavaScript you'd rather avoid writing.
+Finally, we have the **translation stage**. This stage is Marko’s “Rosetta Stone”, and is responsible for turning your beautiful `.marko` code into different versions of optimized JavaScript you’d rather not write yourself.
 
-To hook into the `translate` stage you can use the `translate` option in the `marko.json` file.
+To hook into the `translate` stage, [use the `translate` option in the `marko.json` file](https://markojs.com/docs/marko-json/#paths).
 
 ## Utilities
 
-The [`@marko/babel-utils`](https://github.com/marko-js/marko/tree/master/packages/babel-utils/index.d.ts) package exposes a handful of utilities for performing various tasks on the [Marko AST](#marko-ast).
+[The `@marko/babel-utils` package](https://github.com/marko-js/marko/tree/master/packages/babel-utils/index.d.ts) exposes a handful of utilities for various tasks on [Marko ASTs](#marko-ast).
+
+### Marko AST
 
-## Marko AST
+Marko extends Babel’s AST types to add nodes for `MarkoTag`, `MarkoAttribute`, etc.
 
-Marko extends Babel's AST types adding nodes for `MarkoTag`, `MarkoAttribute`, etc.
-For AST creation and assertion utilities you can import Marko's superset of `@babel/types` through the compiler:
+For AST creation and assertion utilities, you can import Marko’s `@babel/types` superset from the compiler package:
 
 ```js
 import { types } from "@marko/compiler";
 ```
 
-The [`@babel/types` documentation](https://babeljs.io/docs/en/babel-types) shows all the utility methods available for the Babel AST nodes. When importing `types` from `@marko/compiler` you get the same types of utilities for the Marko nodes as well (`types.markoTag`, `types.isMarkoTag`, `types.assertMarkoTag`, etc.).
+The [`@babel/types` documentation](https://babeljs.io/docs/en/babel-types) shows all utility methods available for Babel AST nodes. When importing `types` from `@marko/compiler`, you also get the same types of utilities for Marko nodes: `types.markoTag`, `types.isMarkoTag`, `types.assertMarkoTag`, and so on.
 
-For a full list of definitions, view the source code for Babel and Marko:
+For full definitions, view the source code for Babel and Marko:
 
-- [Babel's Core Definitions](https://github.com/babel/babel/blob/master/packages/babel-types/src/definitions/core.js)
-- [Babel's Extended Definitions](https://github.com/babel/babel/tree/master/packages/babel-types/src/definitions)
-- [Marko's Definitions](https://github.com/marko-js/marko/blob/master/packages/compiler/src/babel-types/types/definitions.js)
+- [Babel’s Core Definitions](https://github.com/babel/babel/blob/master/packages/babel-types/src/definitions/core.js)
+- [Babel’s Extended Definitions](https://github.com/babel/babel/tree/master/packages/babel-types/src/definitions)
+- [Marko’s Definitions](https://github.com/marko-js/marko/blob/master/packages/compiler/src/babel-types/types/definitions.js)

package/docs/vite.md

@@ -38,7 +38,7 @@ if (process.env.NODE_ENV === "production") {
   loadTemplate = () => import("./dist");
 } else {
   // Hookup the vite dev server.
-  const vite = await createViteServer({
+  const vite = await createServer({
     server: { middlewareMode: true }
   });
 

package/package.json

@@ -1,11 +1,11 @@
 {
     "name": "marko",
-    "version": "5.21.8",
+    "version": "5.21.10",
     "license": "MIT",
     "description": "UI Components + streaming, async, high performance, HTML templating for Node.js and the browser.",
     "dependencies": {
-        "@marko/compiler": "^5.22.5",
-        "@marko/translator-default": "^5.21.3",
+        "@marko/compiler": "^5.22.9",
+        "@marko/translator-default": "^5.21.7",
         "app-module-path": "^2.2.0",
         "argly": "^1.2.0",
         "browser-refresh-client": "1.1.4",