ember.nvp 1.7.0 → 1.8.0

package/.github/workflows/ci.yml

@@ -28,6 +28,28 @@ jobs:
       - uses: wyvox/action@v1
       - run: pnpm lint
 
+  babel_8:
+    name: "Node Tests (@babel/core 8)"
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+
+    steps:
+      - uses: wyvox/action@v1
+      # The plugin packages accept Babel 7 and 8, and the lockfile resolves 7.
+      # The blueprint fixtures still need 7 (ember-cli-babel, broccoli), so the
+      # bump is scoped to the three packages that declare the wider range.
+      - run: |
+          cat >> pnpm-workspace.yaml <<'EOF'
+
+          overrides:
+            "@nullvoxpopuli/ember-build-tooling-utils>@babel/core": "^8.0.0"
+            "@nullvoxpopuli/ember-rolldown>@babel/core": "^8.0.0"
+            "@nullvoxpopuli/ember-rolldown>@babel/plugin-transform-typescript": "^8.0.0"
+            "@nullvoxpopuli/ember-vite>@babel/core": "^8.0.0"
+          EOF
+      - run: pnpm install --no-frozen-lockfile
+      - run: pnpm test:node packages/
+
   node_tests:
     name: "Node Tests (${{ matrix.slice.name }})"
     runs-on: ubuntu-latest

package/.release-plan.json

@@ -2,8 +2,8 @@
   "solution": {
     "ember.nvp": {
       "impact": "minor",
-      "oldVersion": "1.6.0",
-      "newVersion": "1.7.0",
+      "oldVersion": "1.7.1",
+      "newVersion": "1.8.0",
       "tagName": "latest",
       "constraints": [
         {
@@ -14,14 +14,28 @@
       "pkgJSONPath": "./package.json"
     },
     "@nullvoxpopuli/ember-build-tooling-utils": {
-      "oldVersion": "1.1.0"
+      "impact": "minor",
+      "oldVersion": "1.1.1",
+      "newVersion": "1.2.0",
+      "tagName": "latest",
+      "constraints": [
+        {
+          "impact": "minor",
+          "reason": "Appears in changelog section :rocket: Enhancement"
+        }
+      ],
+      "pkgJSONPath": "./packages/build-tooling-utils/package.json"
     },
     "@nullvoxpopuli/ember-rolldown": {
       "impact": "minor",
-      "oldVersion": "2.7.0",
-      "newVersion": "2.8.0",
+      "oldVersion": "2.8.1",
+      "newVersion": "2.9.0",
       "tagName": "latest",
       "constraints": [
+        {
+          "impact": "patch",
+          "reason": "Has dependency `workspace:*` on @nullvoxpopuli/ember-build-tooling-utils"
+        },
         {
           "impact": "minor",
           "reason": "Appears in changelog section :rocket: Enhancement"
@@ -30,8 +44,22 @@
       "pkgJSONPath": "./packages/rolldown/package.json"
     },
     "@nullvoxpopuli/ember-vite": {
-      "oldVersion": "1.1.0"
+      "impact": "minor",
+      "oldVersion": "1.1.1",
+      "newVersion": "1.2.0",
+      "tagName": "latest",
+      "constraints": [
+        {
+          "impact": "patch",
+          "reason": "Has dependency `workspace:*` on @nullvoxpopuli/ember-build-tooling-utils"
+        },
+        {
+          "impact": "minor",
+          "reason": "Appears in changelog section :rocket: Enhancement"
+        }
+      ],
+      "pkgJSONPath": "./packages/vite/package.json"
     }
   },
-  "description": "## Release (2026-09-15)\n\n* ember.nvp 1.7.0 (minor)\n* @nullvoxpopuli/ember-rolldown 2.8.0 (minor)\n\n#### :rocket: Enhancement\n* `ember.nvp`, `@nullvoxpopuli/ember-rolldown`\n  * [#130](https://github.com/NullVoxPopuli/ember.nvp/pull/130) Add a custom element project type, and a bundle mode for ember-rolldown ([@NullVoxPopuli-ai-agent](https://github.com/NullVoxPopuli-ai-agent))\n\n#### Committers: 1\n- @NullVoxPopuli's reduced-access machine account for AI usage ([@NullVoxPopuli-ai-agent](https://github.com/NullVoxPopuli-ai-agent))\n"
+  "description": "## Release (2026-09-21)\n\n* ember.nvp 1.8.0 (minor)\n* @nullvoxpopuli/ember-build-tooling-utils 1.2.0 (minor)\n* @nullvoxpopuli/ember-rolldown 2.9.0 (minor)\n* @nullvoxpopuli/ember-vite 1.2.0 (minor)\n\n#### :rocket: Enhancement\n* `ember.nvp`, `@nullvoxpopuli/ember-build-tooling-utils`, `@nullvoxpopuli/ember-rolldown`, `@nullvoxpopuli/ember-vite`\n  * [#135](https://github.com/NullVoxPopuli/ember.nvp/pull/135) Accept @babel/core 8 in the plugin packages ([@NullVoxPopuli](https://github.com/NullVoxPopuli))\n\n#### Committers: 1\n- [@NullVoxPopuli](https://github.com/NullVoxPopuli)\n"
 }

package/CHANGELOG.md

@@ -1,5 +1,37 @@
 # Changelog
 
+## Release (2026-09-21)
+
+* ember.nvp 1.8.0 (minor)
+* @nullvoxpopuli/ember-build-tooling-utils 1.2.0 (minor)
+* @nullvoxpopuli/ember-rolldown 2.9.0 (minor)
+* @nullvoxpopuli/ember-vite 1.2.0 (minor)
+
+#### :rocket: Enhancement
+* `ember.nvp`, `@nullvoxpopuli/ember-build-tooling-utils`, `@nullvoxpopuli/ember-rolldown`, `@nullvoxpopuli/ember-vite`
+  * [#135](https://github.com/NullVoxPopuli/ember.nvp/pull/135) Accept @babel/core 8 in the plugin packages ([@NullVoxPopuli](https://github.com/NullVoxPopuli))
+
+#### Committers: 1
+- [@NullVoxPopuli](https://github.com/NullVoxPopuli)
+
+## Release (2026-09-15)
+
+* ember.nvp 1.7.1 (patch)
+* @nullvoxpopuli/ember-build-tooling-utils 1.1.1 (patch)
+* @nullvoxpopuli/ember-rolldown 2.8.1 (patch)
+* @nullvoxpopuli/ember-vite 1.1.1 (patch)
+
+#### :bug: Bug Fix
+* `ember.nvp`
+  * [#134](https://github.com/NullVoxPopuli/ember.nvp/pull/134) Break the import cycle that hangs the CLI on startup ([@NullVoxPopuli-ai-agent](https://github.com/NullVoxPopuli-ai-agent))
+
+#### :memo: Documentation
+* `ember.nvp`, `@nullvoxpopuli/ember-build-tooling-utils`, `@nullvoxpopuli/ember-rolldown`, `@nullvoxpopuli/ember-vite`
+  * [#132](https://github.com/NullVoxPopuli/ember.nvp/pull/132) Prose pass: reflow comments and READMEs ([@NullVoxPopuli-ai-agent](https://github.com/NullVoxPopuli-ai-agent))
+
+#### Committers: 1
+- @NullVoxPopuli's reduced-access machine account for AI usage ([@NullVoxPopuli-ai-agent](https://github.com/NullVoxPopuli-ai-agent))
+
 ## Release (2026-09-15)
 
 * ember.nvp 1.7.0 (minor)

package/README.md

@@ -5,10 +5,14 @@ _ember project generator: a reenvisioning of blueprints -- hopefully one day to
 > [!NOTE]
 > **Why isn't this work happening in the default blueprints?** for a long time now, I've felt the old blueprint system from the very early days of ember-cli has not allowed for expressive enough layering of what people actually want out of a project generator. That said, that means there are some compromises in the CLI/generator in this repo. Throughout all files generated, whenever there is a caveat, there will be a comment in the file with the caveat, explaining status, open issues, and how we can collectively move forward. It's possible that one day ember-cli adopts or is inspired by this project, but it's too early to tell at the moment.
 
-_I can't recommend using this tool unless your comfortable with the emitted caveats in the project_.
-(And being comfortable debugging build issues is recommended)
+_I can't recommend using this tool unless you're comfortable with the emitted caveats in the project_.
+(And with debugging build issues.)
 
-But I'm very excited about this tool, because it's everything I've ever wanted from a project generator. Each layer is idempotent, and knows about the other layers. So if, for example, you omit eslint when setting up your project, but do have github-actions, when you do add eslint, your github-actions will be updated as well. And this works in any order.
+But I'm very excited about this tool, because it's everything I've ever wanted from a project generator.
+Each layer is idempotent, and knows about the other layers.
+For example: set up a project with github-actions but without eslint.
+When you add eslint later, your github-actions are updated as well.
+This works in any order.
 
 ## Usage
 
@@ -32,21 +36,25 @@ npx NullVoxPopuli/ember.nvp
 
 ### Updating an existing project
 
-You can run `ember.nvp` on top of an existing project to add layers to it. Generation never writes directly to your project -- everything runs in a staging directory first, and before finishing you choose to:
+You can run `ember.nvp` on top of an existing project to add layers to it.
+Nothing is written to your project until you confirm. Before finishing, you choose to:
 
-- **write the files** -- apply all of the staged changes
-- **review the diff** -- step through each changed file's diff, accepting or rejecting it individually (or accept/reject everything remaining)
-- **cancel** -- discard everything; your project is untouched
+- **write the files**: apply all of the staged changes
+- **review the diff**: step through each changed file, and accept or reject it (or accept / reject everything remaining)
+- **cancel**: discard everything. Your project is untouched.
 
-Only files that actually changed are written. `node_modules`, `.git`, and everything else in your project are left alone, and the accepted changes land as uncommitted edits for you to review with your own git tooling.
+Only files that actually changed are written.
+`node_modules`, `.git`, and everything else in your project are left alone.
+The accepted changes land as uncommitted edits, for you to review with your own git tooling.
 
-New projects skip the confirmation and are written as soon as generation succeeds. For scripting, `--write yes` / `--write no` answers the confirmation up front.
+New projects skip the confirmation, and are written as soon as generation succeeds.
+For scripting, `--write yes` / `--write no` answers the confirmation up front.
 
 ### Wrapping
 
-The provided CLI is only a wrapper around our exported `generateProject` function.
+The provided CLI is only a wrapper around the exported `generateProject` function.
 
-Other tools can call `generateProject` themselves if they wish to provide a different terminal or graphical UI.
+Other tools can call `generateProject` themselves, to provide a different terminal or graphical UI.
 
 ```js
 import { generateProject, Project } from 'ember.nvp';
@@ -67,7 +75,9 @@ await generateProject(new Project(
 
 All parts of the generator are idempotent, so running generators on existing projects _can_ no-op.
 
-To get the same don't-write-until-confirmed behavior as the CLI, wrap generation in a `Stage`. A stage is a real directory in the OS temp dir, seeded with a copy of the target directory's current contents (sans `node_modules`/`.git`) -- so layers run against the project's existing state with plain `node:fs`, `ember-apply`, and subprocesses, and authoring a layer is exactly the same with or without one.
+To get the same don't-write-until-confirmed behavior as the CLI, wrap generation in a `Stage`.
+A stage is a scratch copy of the target directory (without `node_modules` and `.git`).
+Layers run against that copy, and the target directory is untouched until you commit.
 
 ```js
 import { generateProject, Project, Stage } from "ember.nvp";
@@ -94,8 +104,9 @@ await stage.commit(); // write the changes to the target directory
 - Modern, incremental
 - Interactive CLI
   - choose your features
-- The generators fro the different types of projects are never out of date from each other
-  - each feature/layer is a mini codemod that has to support working within all the other layers -- so eslint for example is always derived the same way -- no way for "app" and "library" configs to get out of sync
+- The generators for the different types of projects are never out of date from each other
+  - each feature/layer is a mini codemod that has to work within all the other layers.
+    eslint, for example, is always derived the same way: "app" and "library" configs can't get out of sync
 
 Good for:
 
@@ -106,8 +117,9 @@ Good for:
 
 ## Layers
 
-Each layer is a standalone module that can add features to your ember project,
-and every layer is aware of the other layers, so if, for example, you run github actions first, and then later decide to add linting, the github actions output will be updated.
+Each layer is a standalone module that adds a feature to your ember project.
+Every layer is aware of the other layers.
+For example: add github actions first, and linting later. The github actions output is updated.
 
 ### 🎯 Minimal (always included)
 
@@ -126,7 +138,8 @@ Perfect for demos, reproductions, and learning!
 
 Runs `git init` for you.
 
-By default this layer is enabled, _unless_ you are running the generator in a git repo already -- then you have to opt in to git.
+This layer is enabled by default, _unless_ you run the generator inside a git repo already.
+In that case, you have to opt in to git.
 
 ### GitHub Actions (optional)
 
@@ -163,17 +176,17 @@ Super experimental vitest setup using [ember-vitest](https://github.com/NullVoxP
 
 ### How Layers Work
 
-1. **Discovery**: CLI scans `src/layers/` and imports each `index.js`
-2. **Selection**: User selects which optional layers to include
-3. **Execution**: Each layer's `run()` function is called in sequence:
+1. **Discovery**: the CLI scans `src/layers/` and imports each `index.js`
+2. **Selection**: the user selects which optional layers to include
+3. **Execution**: each layer's `run()` function is called in sequence:
    ```js
    await layer.run(project);
    ```
-4. **Layer Functions**: Inside `run()`, layers use [`ember-apply`](https://ember-apply.pages.dev/) to apply codemods in order to:
-   - Copy files from `files/` directory
-   - Add dependencies/devDependencies to package.json
-   - Add npm scripts
-   - Modify package.json metadata
+4. **Layer Functions**: inside `run()`, layers use [`ember-apply`](https://ember-apply.pages.dev/) to apply codemods:
+   - copy files from the `files/` directory
+   - add dependencies / devDependencies to package.json
+   - add npm scripts
+   - modify package.json metadata
    - etc
 
 ### Adding New Layers
@@ -206,7 +219,7 @@ export default {
 };
 ```
 
-2. **`files/`** directory - Template files to copy:
-   - Files will be copied to the target directory maintaining structure
+2. **`files/`** directory: template files to copy
+   - files are copied to the target directory, keeping their structure
 
-The CLI will automatically discover and offer it as an option!
+The CLI discovers the layer and offers it as an option.

package/RELEASE.md

@@ -1,27 +1,29 @@
 # Release Process
 
-Releases in this repo are mostly automated using [release-plan](https://github.com/embroider-build/release-plan/). Once you label all your PRs correctly (see below) you will have an automatically generated PR that updates your CHANGELOG.md file and a `.release-plan.json` that is used to prepare the release once the PR is merged.
+Releases in this repo are mostly automated with [release-plan](https://github.com/embroider-build/release-plan/).
+Once you label all your PRs correctly (see below), a PR is generated for you.
+That PR updates CHANGELOG.md and `.release-plan.json`. Merging it prepares the release.
 
 ## Preparation
 
-Since the majority of the actual release process is automated, the remaining tasks before releasing are:
+Most of the release process is automated. The remaining tasks before a release are:
 
-- correctly labeling **all** pull requests that have been merged since the last release
-- updating pull request titles so they make sense to our users
+- label **all** pull requests merged since the last release
+- update pull request titles so they make sense to our users
 
-Some great information on why this is important can be found at [keepachangelog.com](https://keepachangelog.com/en/1.1.0/), but the overall
-guiding principle here is that changelogs are for humans, not machines.
+[keepachangelog.com](https://keepachangelog.com/en/1.1.0/) explains why this matters.
+The guiding principle: changelogs are for humans, not machines.
 
-When reviewing merged PR's the labels to be used are:
+When reviewing merged PRs, use these labels:
 
-- breaking - Used when the PR is considered a breaking change.
-- enhancement - Used when the PR adds a new feature or enhancement.
-- bug - Used when the PR fixes a bug included in a previous release.
-- documentation - Used when the PR adds or updates documentation.
-- internal - Internal changes or things that don't fit in any other category.
+- breaking: the PR is a breaking change
+- enhancement: the PR adds a new feature or enhancement
+- bug: the PR fixes a bug included in a previous release
+- documentation: the PR adds or updates documentation
+- internal: internal changes, or anything that fits no other category
 
-**Note:** `release-plan` requires that **all** PRs are labeled. If a PR doesn't fit in a category it's fine to label it as `internal`
+**Note:** `release-plan` requires that **all** PRs are labeled. If a PR fits no category, label it `internal`.
 
 ## Release
 
-Once the prep work is completed, the actual release is straight forward: you just need to merge the open [Plan Release](https://github.com/NullVoxPopuli/ember.nvp/pulls?q=is%3Apr+is%3Aopen+%22Prepare+Release%22+in%3Atitle) PR
+Once the prep work is done, the release itself is one step: merge the open [Plan Release](https://github.com/NullVoxPopuli/ember.nvp/pulls?q=is%3Apr+is%3Aopen+%22Prepare+Release%22+in%3Atitle) PR.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ember.nvp",
-  "version": "1.7.0",
+  "version": "1.8.0",
   "description": "ember project generator, alternative to the official blueprints, but more modern -- hopefully one day to upstream back in to ember-cli / official blueprints",
   "repository": {
     "type": "git",

package/packages/build-tooling-utils/README.md

@@ -4,29 +4,24 @@ Shared build tooling for the `@nullvoxpopuli` ember meta-plugins
 ([`@nullvoxpopuli/ember-vite`](../vite) and
 [`@nullvoxpopuli/ember-rolldown`](../rolldown)).
 
-It's intentionally bundler-agnostic (no `vite`/`rolldown` dependency) so both
-meta-plugins can consume the same logic.
+It has no `vite` or `rolldown` dependency, so both meta-plugins can use it.
 
-Requires node 24+, and — since this package ships TypeScript source — a
-modern TypeScript when type-checking: 6+ with `lib` covering `es2025` (e.g.
-`esnext`).
+Requires node 24+. This package ships TypeScript source, so type-checking
+needs TypeScript 6+ with `lib` covering `es2025` (for example `esnext`).
 
 ## Exports
 
 ### `maybeBabel(options?)`
 
-A babel plugin (`@rollup/plugin-babel`) wrapped in a
-[`@rolldown/pluginutils`](https://github.com/rolldown/rolldown) filter so babel
-runs **only** on files that actually need it:
+A babel plugin that runs **only** on the files that need babel:
 
 - template-tag files (`.gts`/`.gjs`)
 - files importing template/macro modules (`@ember/template-compiler`,
   `@embroider/macros`, …)
 - local (non-`node_modules`) code using decorators
 
-Everything else skips babel and is handled by the bundler's native (oxc)
-transform. The point: don't buy rolldown/oxc speed and then give it all back by
-routing every module through babel.
+Everything else uses the bundler's native (oxc) transform, which keeps the
+build fast.
 
 `options` extends `@rollup/plugin-babel`'s options, plus a `filter.include`
 (`imports` / `code`) to opt additional files in.
@@ -34,4 +29,4 @@ routing every module through babel.
 ### `extensions`
 
 The list of file extensions ember source can be authored in. Mirrors
-embroider's canonical list (see `extensions.ts` for details).
+embroider's list.

package/packages/build-tooling-utils/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nullvoxpopuli/ember-build-tooling-utils",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "description": "Shared build tooling for @nullvoxpopuli ember meta-plugins: maybeBabel (run babel only where needed) and the ember file extensions list.",
   "type": "module",
   "main": "index.ts",
@@ -28,7 +28,7 @@
   },
   "packageManager": "pnpm@10.28.0",
   "dependencies": {
-    "@babel/core": "^7.28.10",
+    "@babel/core": "^7.28.10 || ^8.0.0",
     "@rolldown/pluginutils": "^1.0.1",
     "@rollup/plugin-babel": "^7.1.0"
   },

package/packages/build-tooling-utils/src/extensions.ts

@@ -1,9 +1,10 @@
 /**
  * The file extensions ember source can be authored in.
  *
- * Mirrors embroider's canonical list, which is only exported from
- * `@embroider/vite` (its `src/ember.ts`) — copied rather than depended on so
- * this shared tooling stays bundler-agnostic. Keep in sync.
+ * Mirrors embroider's canonical list, which is only exported from `@embroider/vite` (its `src/ember.ts`).
+ * Copied rather than depended on, so this shared tooling stays bundler-agnostic.
+ *
+ * Keep in sync.
  */
 export const extensions = [
   ".mjs",

package/packages/build-tooling-utils/src/maybe-babel.ts

@@ -5,14 +5,16 @@
  * - scoped-css
  * - template compilation optimization
  *
- * `maybeBabel` runs babel ONLY on the files that actually need it (template-tag
- * files, files importing template/macro modules, and local code using
- * decorators). Everything else skips babel so the bundler's native (oxc)
- * transform handles it -- the whole point being to keep the fast path fast and
- * not re-slow the build by sending every file through babel.
+ * `maybeBabel` runs babel ONLY on the files that actually need it:
+ * - template-tag files
+ * - files importing template/macro modules
+ * - local code using decorators
  *
- * This is shared between the vite (app) and rolldown/tsdown (library)
- * meta-plugins.
+ * Everything else skips babel, so the bundler's native (oxc) transform handles it.
+ * The whole point is to keep the fast path fast,
+ * and not re-slow the build by sending every file through babel.
+ *
+ * This is shared between the vite (app) and rolldown/tsdown (library) meta-plugins.
  */
 import { and, code, id, include, not, or } from "@rolldown/pluginutils";
 import { babel } from "@rollup/plugin-babel";
@@ -21,8 +23,10 @@ import type { RollupBabelInputPluginOptions } from "@rollup/plugin-babel";
 import { extensions } from "./extensions.ts";
 
 /**
- * If a file imports any of these, it needs babel (templates, macros, and a
- * couple of addons that ship decorator-adjacent runtime code).
+ * If a file imports any of these, it needs babel:
+ * - templates
+ * - macros
+ * - a couple of addons that ship decorator-adjacent runtime code
  */
 const babelRequiredImports = [
   // Templates
@@ -65,20 +69,20 @@ type Options = Omit<RollupBabelInputPluginOptions, "filter"> & {
   filter?: {
     include: {
       /**
-       * If any additional (custom) plugins are provided, a pattern
-       * should be provided that detects their usage
+       * If any additional (custom) plugins are provided,
+       * a pattern must be provided that detects their usage.
        *
        * for example, to also run babel on files that import from ember-concurrency
        * ```js
        * {
-       *   code: ['ember-concurrency'],
+       *   imports: ['ember-concurrency'],
        * }
        * ```
        */
       imports: string[];
       /**
-       * If any additional (custom) plugins are provided, a pattern
-       * should be provided that detects their usage
+       * If any additional (custom) plugins are provided,
+       * a pattern must be provided that detects their usage.
        *
        * for example, to also run babel on files that use polyfilled APIs,
        * or use the "formatMessage" technique for translations
@@ -121,7 +125,6 @@ export function maybeBabel(userOptions: Options = {}) {
           id(/\.gjs$/),
           // imports one of the modules above
           code(importsRegex),
-          // (a common way to do translations)
           // local app code using a decorator
           // NOTE: maybeBabel requires that all libraries compile away their decorators
           //