ember.nvp 1.6.0 → 1.7.1

package/packages/rolldown/src/transform.ts

@@ -7,9 +7,10 @@ import type { Plugin } from "rolldown";
 const processor = new Preprocessor();
 
 /**
- * `.d.ts` files emitted for `.gts` source reference the original `.gts`
- * specifiers. Consumers can't resolve those, so we rewrite them back to
- * extension-less specifiers.
+ * `.d.ts` files emitted for `.gts` source reference the original `.gts` specifiers.
+ *
+ * Consumers can't resolve those,
+ * so we rewrite them back to extension-less specifiers.
  */
 function fixDeclarationImports(content: string): string {
   return content
@@ -41,10 +42,12 @@ async function fixDtsExtensionsInDir(dir: string): Promise<void> {
 /**
  * A sourcemap mapping every generated line to the same line of the input.
  *
- * `AAAA` is the [0, 0, 0, 0] VLQ segment (first line maps to source 0, line 0,
- * column 0); `AACA` is [0, 0, +1, 0] (each following line advances the source
- * line by one). Exact at line granularity, which is all the specifier rewrite
- * can disturb.
+ * - `AAAA` is the [0, 0, 0, 0] VLQ segment
+ *   (first line maps to source 0, line 0, column 0)
+ * - `AACA` is [0, 0, +1, 0]
+ *   (each following line advances the source line by one)
+ *
+ * Exact at line granularity, which is all the specifier rewrite can disturb.
  */
 function lineIdentityMap(id: string, source: string) {
   return {
@@ -60,8 +63,10 @@ function lineIdentityMap(id: string, source: string) {
 }
 
 /**
- * Maps `.gts` -> `.ts` and `.gjs` -> `.js` (so rolldown can identify them as
- * ts/js) and preprocesses `<template>` via content-tag.
+ * Preprocesses `<template>` via content-tag, and maps
+ *   `.gts` → `.ts`
+ *   `.gjs` → `.js`
+ * so rolldown can identify them as ts / js.
  */
 export function emberTransform(): Plugin {
   return {
@@ -70,21 +75,26 @@ export function emberTransform(): Plugin {
     resolveId: {
       order: "pre",
       handler(id, importer) {
-        // Entries have no importer: their ids come straight from the build
-        // config (tsdown expands entry globs to on-disk paths). Resolve a
-        // `.gts`/`.gjs` entry to the same virtual `.ts`/`.js` id an imported
-        // module gets, so the load hook compiles it via content-tag instead
-        // of the raw `<template>` source hitting the parser. Entries may be
-        // any extension — the emitted `.js`/`.d.ts` paths mirror the entry
-        // paths either way (that's how tsdown's dts support works).
+        // Entries have no importer.
+        // Their ids come straight from the build config
+        // (tsdown expands entry globs to on-disk paths).
+        //
+        // Resolve a `.gts` / `.gjs` entry to the same virtual `.ts` / `.js` id
+        // an imported module gets, so the load hook compiles it via content-tag
+        // instead of the raw `<template>` source hitting the parser.
+        //
+        // Entries may be any extension.
+        // The emitted `.js` / `.d.ts` paths mirror the entry paths either way
+        // (that's how tsdown's dts support works).
         if (!importer) {
           if (!id.endsWith(".gts") && !id.endsWith(".gjs")) return null;
           if (!existsSync(id)) return null;
 
-          // rolldown's default resolver realpaths entry ids (e.g. macOS
-          // /var -> /private/var). Match it, or this same file imported from
-          // another entry resolves to a second module id and gets duplicated
-          // into both chunks.
+          // rolldown's default resolver realpaths entry ids
+          // (e.g. macOS /var -> /private/var).
+          //
+          // Match it, or this same file imported from another entry
+          // resolves to a second module id and gets duplicated into both chunks.
           const fileName = realpathSync(path.resolve(id));
 
           return {
@@ -93,13 +103,16 @@ export function emberTransform(): Plugin {
           };
         }
 
-        // An absolute specifier already names the file, so it needs no
-        // importer-relative resolution — and joining it onto the importer's
-        // directory would corrupt it. That is not hypothetical: a plugin's
-        // virtual module (id prefixed with `\0`) can generate imports of
-        // on-disk files by absolute path, and `path.dirname("\0./registry")`
-        // is `"\0."`, so joining yields `"\0./Users/.../thing.gts"` — a path
-        // no `existsSync`/`readFile` can accept (it has a null byte in it).
+        // An absolute specifier already names the file,
+        // so it needs no importer-relative resolution.
+        // Joining it onto the importer's directory would corrupt it.
+        //
+        // That is not hypothetical.
+        // A plugin's virtual module (id prefixed with `\0`)
+        // can generate imports of on-disk files by absolute path,
+        // and `path.dirname("\0./registry")` is `"\0."`.
+        // Joining then yields `"\0./Users/.../thing.gts"`:
+        // a path no `existsSync` / `readFile` can accept (it has a null byte in it).
         const fileName = path.isAbsolute(id) ? id : path.join(path.dirname(importer), id);
 
         if (id.endsWith(".gts")) {
@@ -116,15 +129,19 @@ export function emberTransform(): Plugin {
           };
         }
 
-        // A `.ts`/`.js` specifier whose only backing file is a `.gts`/`.gjs`
-        // resolves to the virtual module. This must also serve `.d.ts`
-        // importers: rolldown-plugin-dts resolves a declaration module's
-        // imports through the plugin pipeline (`this.resolve`), and — when the
-        // resolution is a source file — loads it (registering its declaration)
-        // before mapping the import to the declaration id. Virtual modules
-        // exist nowhere else, so if we don't answer here the import either
-        // fails to resolve (no file on disk) or, worse, resolves to a
-        // declaration id that was never registered.
+        // A `.ts` / `.js` specifier whose only backing file is a `.gts` / `.gjs`
+        // resolves to the virtual module.
+        //
+        // This must also serve `.d.ts` importers.
+        // rolldown-plugin-dts resolves a declaration module's imports
+        // through the plugin pipeline (`this.resolve`).
+        // When the resolution is a source file, it loads it (registering its declaration)
+        // before mapping the import to the declaration id.
+        //
+        // Virtual modules exist nowhere else.
+        // If we don't answer here, the import either:
+        // - fails to resolve (no file on disk)
+        // - or, worse, resolves to a declaration id that was never registered
         if (id.endsWith(".ts")) {
           const gtsFileName = fileName.replace(/\.ts$/, ".gts");
           if (existsSync(gtsFileName) && !existsSync(fileName)) {
@@ -152,9 +169,11 @@ export function emberTransform(): Plugin {
         const meta = this.getModuleInfo(id)?.meta ?? {};
         let fileName = meta?.fileName;
 
-        // A virtual id can be loaded without having passed through our
-        // resolveId (rolldown-plugin-dts calls `this.load({ id })` with just
-        // the id), so no meta is attached: recover the backing file from disk.
+        // A virtual id can be loaded without having passed through our resolveId
+        // (rolldown-plugin-dts calls `this.load({ id })` with just the id),
+        // so no meta is attached.
+        //
+        // Recover the backing file from disk.
         if (!fileName && !existsSync(id)) {
           if (id.endsWith(".ts") && existsSync(id.replace(/\.ts$/, ".gts"))) {
             fileName = id.replace(/\.ts$/, ".gts");
@@ -188,12 +207,13 @@ export function emberTransform(): Plugin {
         id: /\.(js|ts)$/,
       },
       handler(input, id) {
-        // Rewrite `.gts` specifiers to `.ts` — the (virtual) source id — in
-        // runtime modules AND declaration modules alike. Declaration modules
-        // must NOT be rewritten to `.d.ts`: rolldown-plugin-dts's resolver
-        // treats a source-file resolution as "load it (registering its
-        // declaration), then map to the declaration id", while a `.d.ts` id is
-        // returned as-is — unloadable when the module isn't registered yet
+        // Rewrite `.gts` specifiers to `.ts`, the (virtual) source id,
+        // in runtime modules AND declaration modules alike.
+        //
+        // Declaration modules must NOT be rewritten to `.d.ts`.
+        // rolldown-plugin-dts's resolver treats a source-file resolution as
+        // "load it (registering its declaration), then map to the declaration id".
+        // A `.d.ts` id is returned as-is: unloadable when the module isn't registered yet
         // (e.g. the `.gts` is only ever type-imported).
         const output = input.replace(
           /(['"`])((?:\.\.?\/|\/|@|[A-Za-z0-9_\-])[^'"]*?\.gts)\1/g,
@@ -204,9 +224,9 @@ export function emberTransform(): Plugin {
           return null;
         }
 
-        // The rewrite only shortens import specifiers in place, so a
-        // line-identity map is accurate to the line (and to the column for
-        // everything before the first rewritten specifier on a line).
+        // The rewrite only shortens import specifiers in place,
+        // so a line-identity map is accurate to the line
+        // (and to the column, for everything before the first rewritten specifier on a line).
         return { code: output, map: lineIdentityMap(id, input) };
       },
     },

package/packages/vite/README.md

@@ -8,30 +8,29 @@ A speed-optimized default meta-config for ember projects.
 npm add @nullvoxpopuli/ember-vite
 ```
 
-Requires node 24+, and — since these packages ship TypeScript source — a
-modern TypeScript when type-checking: 6+ with `lib` covering `es2025` (e.g.
-`esnext`).
+Requires node 24+. These packages ship TypeScript source, so type-checking
+needs TypeScript 6+ with `lib` covering `es2025` (for example `esnext`).
 
 ## Usage
 
-in your vite config
+In your vite config:
 
 ```js
 import { defineConfig } from "vite";
 import { ember } from "@nullvoxpopuli/ember-vite";
 
 export default defineConfig({
-  plugins: [
-    ember(),
-  ],
-}
+  plugins: [ember()],
+});
 ```
 
-And remove any plugins from embroider or babel.
-Then delete from your package.json: `@rollup/plugin-babel`, `@embroider/core`, `@embroider/vite`.
+Then:
+
+1. Remove any plugins from embroider or babel.
+2. Delete from your package.json: `@rollup/plugin-babel`, `@embroider/core`, `@embroider/vite`.
 
 > [!NOTE]
-> babel related deps are still needed for linting, so don't delete those
+> Linting still needs the babel related deps, so keep those.
 
 ## Requirements
 

package/packages/vite/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nullvoxpopuli/ember-vite",
-  "version": "1.1.0",
+  "version": "1.1.1",
   "description": "Meta plugin for ember projects focusing on speed.",
   "type": "module",
   "main": "index.ts",

package/packages/vite/src/ember.ts

@@ -19,14 +19,16 @@ function absolutePath(relativePath: string) {
  * Everything a project without its own babel config needs:
  *
  * - TypeScript stripping
- * - template compilation (wire format: vite serves/bundles for the
- *   project's own ember-source, so the final compile happens here)
+ * - template compilation, to the wire format
+ *   (vite serves and bundles for the project's own ember-source,
+ *    so the final compile happens here)
  * - build macros, evaluated at build time
- * - decorator-transforms, with its runtime left as a bare specifier so it
- *   resolves from the project (which depends on `decorator-transforms`)
+ * - decorator-transforms, with its runtime left as a bare specifier
+ *   so it resolves from the project
+ *   (the project depends on `decorator-transforms`)
  *
- * The plugins are named, not imported: babel resolves them from the
- * project, which carries them as its own dependencies.
+ * The plugins are named, not imported.
+ * babel resolves them from the project, which carries them as its own dependencies.
  */
 function defaultBabelPlugins() {
   const macros = buildMacros();
@@ -56,12 +58,14 @@ type BabelOptions =
     };
 
 /**
- * The project's babel config wins when it exists -- `babel.configFile`
- * selects which one (e.g. a test-only `config/test/babel.config.js`).
- * Without one (libraries), `defaultBabelPlugins` covers TypeScript,
- * templates, macros, and decorators, so no config file is required --
- * helpers are inlined because projects without a babel config don't
- * carry `@babel/runtime`.
+ * The project's babel config wins when it exists.
+ * `babel.configFile` selects which one (e.g. a test-only `config/test/babel.config.js`).
+ *
+ * Without one (libraries), `defaultBabelPlugins` covers TypeScript, templates, macros, and decorators,
+ * so no config file is required.
+ *
+ * Helpers are inlined in that case:
+ * projects without a babel config don't carry `@babel/runtime`.
  */
 function babelOptions(nvpConfig: Config): BabelOptions {
   const configFile = resolve(
@@ -83,9 +87,12 @@ function babelOptions(nvpConfig: Config): BabelOptions {
 /**
  * Additional opt-ins beyond maybeBabel's built-in list.
  *
- * These libraries ship code that still needs babel (ember-concurrency's
- * decorators, ember-scoped-css transforms, ember-intl's formatMessage macro),
- * and the `initializeRuntimeMacrosConfig` runtime call must be compiled away.
+ * These libraries ship code that still needs babel:
+ * - ember-concurrency's decorators
+ * - ember-scoped-css transforms
+ * - ember-intl's formatMessage macro
+ *
+ * The `initializeRuntimeMacrosConfig` runtime call must also be compiled away.
  */
 function babelFilter(nvpConfig: Config) {
   return {
@@ -120,9 +127,10 @@ interface Config {
     configFile?: string;
 
     /**
-     * optional way to configure when babel is activateed.
-     * by default, all transforming is oxc, except when babel is needed
-     * (for things not currently implemented in oxc)
+     * optional way to configure when babel is activated.
+     *
+     * by default, all transforming is oxc,
+     * except when babel is needed (for things not currently implemented in oxc)
      */
     include?: {
       /**
@@ -154,10 +162,12 @@ export function ember(nvpConfig: Config = {}) {
   const filter = babelFilter(nvpConfig);
 
   /*
-   * Plugins must be returned as top-level array entries — NOT pushed into
-   * config.plugins inside a config() hook.  Vite 8 extracts user plugins
-   * *before* config hooks run, so anything added later is invisible to the
-   * plugin container (resolveId, load, etc. hooks never fire).
+   * Plugins must be returned as top-level array entries,
+   * NOT pushed into config.plugins inside a config() hook.
+   *
+   * Vite 8 extracts user plugins *before* config hooks run,
+   * so anything added later is invisible to the plugin container
+   * (resolveId, load, etc. hooks never fire).
    */
   return [
     {
@@ -194,9 +204,8 @@ export function ember(nvpConfig: Config = {}) {
           resolver({ rolldown: true }),
           templateTag(),
 
-          // Libraries will have precompileTemplate and macros, etc,
-          // and we need to compile that away using this app's
-          // template compiler
+          // Libraries ship precompileTemplate calls and macros.
+          // Both must compile away here, with this app's template compiler.
           maybeBabel({
             ...babel,
             parallel: nvpConfig.babel?.parallel,
@@ -231,14 +240,12 @@ function applyConfig(viteConfig: ResolvedConfig, env: ConfigEnv, nvpConfig: Conf
 }
 
 function dev(viteConfig: ResolvedConfig, nvpConfig: Config) {
-  /**************************************
-   *
+  /**
    * build config for tests
    *
-   * NOTE: we can't minify because some tests
-   *       are checking x.constructor.name, which changes when minified
-   *
-   *************************************/
+   * NOTE: we can't minify.
+   *       some tests check x.constructor.name, which changes when minified
+   */
   Object.assign(viteConfig.build, {
     sourcemap: true,
     cleanCssOptions: { sourceMap: true },
@@ -333,7 +340,8 @@ function prod(viteConfig: ResolvedConfig, nvpConfig: Config) {
     minify: true,
     cleanDir: true,
     /**
-     * This is needed due to how we manage module state.
+     * Needed due to how we manage module state.
+     *
      * This can create waterfalls when too much top-level await is used.
      */
     strictExecutionOrder: true,
@@ -342,10 +350,10 @@ function prod(viteConfig: ResolvedConfig, nvpConfig: Config) {
      */
     codeSplitting: {
       /**
-       * Kind of a shame this isn't automatic based on dynamic import usage
-       * in vite8.
-       * Kinda forces us to know every potential problem area of the app,
-       * rather than rely on automatic optimizations based on import/module usage
+       * Kind of a shame this isn't automatic based on dynamic import usage in vite8.
+       *
+       * This forces us to know every potential problem area of the app,
+       * rather than rely on automatic optimizations based on import/module usage.
        */
       groups: [...(nvpConfig?.production?.codeSplittingGroups ?? [])],
     },

package/packages/vite/src/test-html.ts

@@ -3,10 +3,10 @@ import { join } from "node:path";
 import type { ViteDevServer } from "vite";
 
 /**
- * Everything a QUnit + testem run needs, with no project-specific
- * references: root-relative specifiers keep it independent of where the
- * project keeps its files, and the globs pick up tests/** as well as
- * co-located `*-test` modules under src/**.
+ * Everything a QUnit + testem run needs, with no project-specific references.
+ *
+ * - root-relative specifiers keep it independent of where the project keeps its files
+ * - the globs pick up tests/** as well as co-located `*-test` modules under src/**
  */
 const DEFAULT_TEST_HTML = `<!doctype html>
 <html>
@@ -39,14 +39,16 @@ const DEFAULT_TEST_HTML = `<!doctype html>
 `;
 
 /**
- * Lets a project run its tests without maintaining a tests/index.html:
- * whenever that file is absent, this plugin answers for it -- `load`
- * supplies the html to the build (so `tests/index.html` still lands in
- * dist for testem), and the dev-server middleware serves it (through
- * `transformIndexHtml`, so the html goes through the same pipeline as an
- * on-disk file).
+ * Lets a project run its tests without maintaining a tests/index.html.
+ *
+ * Whenever that file is absent, this plugin answers for it:
+ * - `load` supplies the html to the build
+ *   (so `tests/index.html` still lands in dist for testem)
+ * - the dev-server middleware serves it, through `transformIndexHtml`,
+ *   so the html goes through the same pipeline as an on-disk file
  *
- * A tests/index.html on disk always wins; every hook here defers to it.
+ * A tests/index.html on disk always wins.
+ * Every hook here defers to it.
  */
 export function testHtml() {
   const htmlPath = join(process.cwd(), "tests", "index.html");

package/src/bases/README.md

@@ -1,5 +1,8 @@
-Each of these base projects are _real_ projects that can be ran in these directories.
+Each base is a _real_ project.
+You can run it from its `files/` directory.
 
-For changing the name of a project, the code in the base layer's index.js should find all the places the name is used and swap it out (codemod style).
+A base never uses a template language such as ejs:
+that would make the base unrunnable.
 
-We don't want to use ejs, because it makes the base layers unrunnable.
+To change the project name, the base's `index.js` finds every place the name is used,
+and swaps it out (codemod style).

package/src/bases/minimal-app/app.test.ts

@@ -110,8 +110,9 @@ const DEBUG_MARKERS = {
 
 /**
  * Lives in app/services/ so that app.ts's eager
- * `import.meta.glob("./services/**\/*")` pulls it into the build
- * without needing to modify any generated files.
+ * `import.meta.glob("./services/**\/*")` pulls it into the build.
+ *
+ * No generated file needs to change.
  */
 const debugFixture = `
 import { assert, deprecate, warn } from "@ember/debug";
@@ -134,8 +135,10 @@ if (macroCondition(isDevelopingApp())) {
 `;
 
 /**
- * Only .js files -- the sourcemaps (.map) contain the original
- * source (with markers) even in production builds.
+ * Only .js files.
+ *
+ * The sourcemaps (.map) contain the original source (with markers),
+ * even in production builds.
  */
 async function builtJavaScript(project: Project): Promise<string> {
   let files = globSync("dist/**/*.js", { cwd: project.directory });

package/src/bases/minimal-app/files/app/app.ts

@@ -1,11 +1,10 @@
 /**
  * Looking for services that come from addons?
  *
+ * App-tree merging from libraries is not supported.
  * See: https://github.com/embroider-build/embroider/issues/2659
  *
- * We currently don't support app-tree merging from libraries.
- *
- * For services, I highly recommend looking in to either of
+ * For services, look in to either of:
  * - https://github.com/chancancode/ember-polaris-service-
  * - https://ember-primitives.pages.dev/6-utils/createService.md
  *   - https://ember-primitives.pages.dev/6-utils/createAsyncService.md

package/src/bases/minimal-app/files/app/router.ts

@@ -10,10 +10,10 @@ export default class Router extends EmbroiderRouter {
 Router.map(function () {});
 
 /**
+ * Route bundles (lazy-loaded route groups) have no nice API yet.
+ *
  * Caveat:
  * - https://github.com/embroider-build/embroider/issues/2521
- *   We don't yet have a way to do this in a nice way
- *
  */
 // function bundle(name: string, loader: () => Promise<{ default: unknown }>[]) {
 //   return {
@@ -35,7 +35,7 @@ Router.map(function () {});
 // }
 
 /**
- * Examples from:
+ * Example usage, from:
  * - https://github.com/NullVoxPopuli/limber/blob/67e2f54bbe224052e38f9a9e566d704411e65e86/apps/repl/app/router.ts#L35
  */
 // (window as any)._embroiderRouteBundles_ = [

package/src/bases/minimal-app/index.js

@@ -5,7 +5,7 @@ import { applyFolderTo } from "#utils/fs.js";
 import { removeConfiguredPlugin } from "#utils/babel.js";
 
 /**
- * Minimal Layer
+ * Minimal App Base
  *
  * Provides the absolute bare minimum for an Ember app:
  * - type: "module" in package.json
@@ -22,8 +22,10 @@ export default {
   /**
    * 1. Apply files
    *   a. Remove TS if needed
-   * 2. Remove TS deps/files if needed
-   * 3. Update name(s)
+   * 2. Update name(s)
+   * 3. Remove TS deps/files if needed
+   * 4. Upgrade in-range dependencies
+   * 5. Update an existing babel config, if any
    *
    * @param {import('#utils/project.js').Project} project
    */
@@ -37,6 +39,8 @@ export default {
 };
 
 /**
+ * A JavaScript project's babel config must not reference the TS plugin.
+ *
  * @param {import('#utils/project.js').Project} project
  */
 async function updateBabelConfig(project) {
@@ -72,10 +76,10 @@ async function makeJavaScript(project) {
   if (await project.hasOrWantsLayer("typescript")) return;
 
   /**
-   * We don't actually remove anything, because we want intellisense for JS
+   * Intellisense for JS needs some of these,
+   * but minimal means minimal.
    *
-   * But perhaps for the sake of minimal, we do remoev it.
-   * And we add a layer later for JSDoc ased TS or something
+   * A later layer for JSDoc-based TS can add them back.
    */
   await packageJson.removeDevDependencies(
     [

package/src/bases/minimal-custom-element/files/README.md

@@ -0,0 +1,95 @@
+# minimal-custom-element
+
+An Ember component, packaged as a
+[custom element](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements)
+and built with
+[`@nullvoxpopuli/ember-rolldown`](https://github.com/NullVoxPopuli/ember.nvp/tree/main/packages/rolldown)
+and [tsdown](https://tsdown.dev/).
+
+`dist/` contains ember and every other dependency. The page that uses the element
+needs nothing else.
+
+## Usage
+
+Import the `register` entry once. It defines the `<minimal-custom-element>` tag.
+
+```js
+import "minimal-custom-element/register";
+```
+
+```html
+<minimal-custom-element label="Clicks" step="2"></minimal-custom-element>
+```
+
+To choose your own tag name, import the class and define it yourself:
+
+```js
+import { CounterElement } from "minimal-custom-element";
+
+customElements.define("my-counter", CounterElement);
+```
+
+Ember apps can import the `Counter` component directly from the package root.
+
+## Development
+
+```bash
+pnpm install
+```
+
+Build the distributable (JS + `.d.ts` into `dist/`):
+
+```bash
+pnpm build
+```
+
+Rebuild on change while developing:
+
+```bash
+pnpm start
+```
+
+## Structure
+
+- `src/components/counter.gts` is the Ember component.
+- `src/element.ts` is the custom element.
+  Its `connectedCallback` renders the component with `renderComponent` from `@ember/renderer`.
+  Its `disconnectedCallback` destroys that render.
+- `src/register.ts` defines the tag.
+  Consumers import this file for its side effect.
+- `src/index.ts` is the public entry point.
+  It exports the element class and the component.
+- `dist/` is the built output that gets published (git-ignored).
+
+### Reactive attributes
+
+The element lists its attributes in `observedAttributes`.
+Each attribute change writes to a tracked object.
+The component reads its args from that object, so the DOM updates on the next render.
+
+To add an attribute:
+
+1. Add its name to `observedAttributes`.
+2. Give it a default value in the tracked object.
+3. Write the new value in `attributeChangedCallback`.
+4. Read it as an arg in the component.
+
+Declarations are emitted with
+[isolated declarations](https://www.typescriptlang.org/tsconfig/#isolatedDeclarations),
+so every exported value needs an explicit type annotation.
+
+### Development or production ember
+
+The build bundles the production build of ember.
+
+To bundle the development build (assertions and deprecation messages),
+add the `development` condition in `tsdown.config.js`:
+
+```js
+inputOptions: { resolve: { conditionNames: ["development"] } },
+```
+
+## Publishing
+
+`dist/` is built automatically on `prepack`, so `npm publish` ships the
+compiled output plus your `src/`.