Codestin Search App

SergeAstapov · 2026-06-18T12:23:47Z

Closes #431.

This is pretty large PR because:

addon needs restructuring, to make architecture modular.
added my-vite-addon test package
added my-vite-app test package
updated documentation

The other way I can make this small and potentially easier to review (if anyone wants to do thorough code review):

have one PR that does restructuring, to make architecture modular.
then introduce Vite support

SergeAstapov · 2026-06-18T12:25:25Z

@@ -0,0 +1,48 @@
+'use strict';


this file prepares for template coverage, to showcase how it would fit into new architecture to make these changes compatible with #433

kategengler · 2026-06-18T16:41:52Z

      - uses: actions/checkout@v4
      - name: Install Node
-        uses: actions/setup-node@v3
+        uses: actions/setup-node@v4


Suggested change

uses: actions/setup-node@v4

uses: actions/setup-node@v6

kategengler · 2026-06-18T16:42:49Z

@@ -20,12 +20,12 @@ jobs:
    steps:
      - uses: actions/checkout@v4


Suggested change

- uses: actions/checkout@v4

- uses: actions/checkout@v6

kategengler

I've started reviewing but will need to continue later.

I'd be okay with dropping support for the old style (telling users in the README to use a particular major).

I also think it would be helpful to explain how the project differs from https://github.com/NullVoxPopuli/testem-code-coverage for vite-based projects.

kategengler · 2026-06-18T16:48:06Z


+### v2 Embroider addons (Rollup-based)
+
+For v2 Embroider native addons based on https://github.com/embroider-build/addon-blueprint blueprint:


This is not the eventual blueprint. That can be found https://github.com/ember-cli/ember-addon-blueprint

I'd prefer to have compatibility with the official blueprint.

we do have compatibility with ember-addon-blueprint, it's under Vite support.

this one is for that previous blueprint where we did have support for some time, but readme just didn't explain how to do it.

at minimum we can swap it with Vite docs to make Vite more prominent. not sure it worth to completely remove this section

kategengler · 2026-06-18T16:48:38Z

+[Classic Ember CLI apps](#classic-ember-cli-apps) or
+[Vite-based apps and addons](#vite-based-apps-and-addons) sections.
+
+### Vite-based apps and addons


We should bump this ahead of the the other instructions since it is the current default for apps and will soon be so for addons

kategengler · 2026-06-18T16:50:34Z

+
+This matches the [ember-addon-blueprint vite.config.mjs](https://github.com/ember-cli/ember-addon-blueprint/blob/main/files/vite.config.mjs):
+
+```js


Can we do these examples as diffs so it is easy to see what needs to be added for the addon vs what is already there?

was thinking the same - will update all examples!

kategengler · 2026-06-18T16:52:48Z

+  plugins: [
+    ...(isCompat ? [classicEmberSupport()] : []),
+    ember(),
+    ...(enableCoverage ? coveragePlugin() : []),


Looks like coverageEnvVar is irrelevant for vite projects, then?

kategengler · 2026-06-18T16:55:58Z

+#### Test helper (`tests/test-helper.js` or `tests/test-helper.ts`)
+
+Instrumentation records hits in `window.__coverage__`, but reports are only written after the browser **POSTs** that payload to `/write-coverage`.
+Wire that up from [`ember-cli-code-coverage/test-support`](https://github.com/ember-cli-code-coverage/ember-cli-code-coverage/tree/master/packages/ember-cli-code-coverage/addon-test-support) in **`tests/test-helper.js`** or **`tests/test-helper.ts`** (same pattern for either extension).


This line is confusing -- the demonstration of the use of it below is enough.

kategengler · 2026-06-18T16:58:24Z

+}
+```
+
+If you use **`vite build` + Testem** (output to `dist-tests` or `dist`), the Vite dev server's `configureServer` hook from `coveragePlugin()` only runs under **`vite dev`**, not during a production-style test build. For this case the addon automatically detects `@embroider/vite` in your project's `package.json` and registers `createViteTestemMiddleware()` for you via its `testemMiddleware` hook — no extra `testem.cjs` configuration is required.


This needs some clarification

kategengler · 2026-06-18T16:59:19Z

-## TypeScript integration
+## TypeScript integration (classic ember-cli / Embroider)
+
+For Vite-based projects, TypeScript is handled natively by Vite/esbuild — no


Lots of implementation details have leaked into these user-facing docs

kategengler · 2026-06-18T17:00:04Z


-* in `ember-cli-build.js
-```
+* in `ember-cli-build.js`


Is this section still relevant?

kategengler · 2026-06-18T18:40:20Z

 };
 ```

+## Migration from v2 to v3


Not sure this belongs in the README, more like a changelog entry

mcfiredrill · 2026-06-29T23:54:22Z

Was wondering if forceModulesToBeLoaded will need to be rewritten to work with vite, or will this function not be needed any more in vite?
https://github.com/ember-cli-code-coverage/ember-cli-code-coverage/blob/master/packages/ember-cli-code-coverage/addon-test-support/index.js#L22C17-L22C39

Closes the three gaps between this branch and what issue ember-cli-code-coverage#431 and PRs ember-cli-code-coverage#433/ember-cli-code-coverage#434 set out to do. Strict-mode template coverage (.gjs/.gts): - createTemplateCoveragePlugin now takes `strict: true`, emitting camelCase helper references (coverageMark) instead of dash-cased ones. The two can't be shared: loose mode resolves helpers by name through the classic resolver, which current ember-resolver versions require to be dash-cased — they removed the camelCase fallback as a deliberate bug fix. Strict mode has no resolver at all, so every reference must be a JS binding, and a dash isn't a valid identifier character. - New templateCoverageImportPlugin supplies those bindings, injecting the three helper imports from a Babel pre() hook so they exist before babel-plugin-ember-template-compilation validates template scope. - Skip templates outside the project and anything under node_modules: Embroider rewrites classic v1 addon dependencies into v2-compatible template() calls through the host app's own `transforms`, and those never went through the import plugin, so instrumenting them broke the build outright. - Derive the coverage key from `env.filename` when the preprocessor registry didn't set `env.meta.moduleName` (it never does on the strict-mode path), so entries no longer collapse onto a shared placeholder key. - Suffix that key so it doesn't resolve to a real file. A .gjs file's own JS coverage has a real source map, and applying it to template positions read off the pre-compilation AST produced invalid columns and crashed reporting for the whole payload. Fix adjustCoverage discarding coverage on key collision: Two raw keys resolving to the same file overwrote rather than merged, so one silently won. Merges via istanbul-lib-coverage now — the template and JS halves of a .gjs file depend on it, and it was already wrong for any other collision. Standalone CLI: `coverage-merge` bin runs the merge without ember-cli, for projects with no ember-cli command layer. Takes optional --root and --config. New /core subpath export, exposing the config, path-mapping and report utilities without pulling in babel, vite, or testem code. Co-Authored-By: Claude Opus 5 <[email protected]>

Closes the three gaps between this branch and what issue ember-cli-code-coverage#431 and PRs ember-cli-code-coverage#433/ember-cli-code-coverage#434 set out to do. Strict-mode template coverage (.gjs/.gts): - createTemplateCoveragePlugin now takes `strict: true`, emitting camelCase helper references (coverageMark) instead of dash-cased ones. The two can't be shared: loose mode resolves helpers by name through the classic resolver, which current ember-resolver versions require to be dash-cased — they removed the camelCase fallback as a deliberate bug fix. Strict mode has no resolver at all, so every reference must be a JS binding, and a dash isn't a valid identifier character. - New templateCoverageImportPlugin supplies those bindings, injecting the three helper imports from a Babel pre() hook so they exist before babel-plugin-ember-template-compilation validates template scope. - Skip templates outside the project and anything under node_modules: Embroider rewrites classic v1 addon dependencies into v2-compatible template() calls through the host app's own `transforms`, and those never went through the import plugin, so instrumenting them broke the build outright. - Derive the coverage key from `env.filename` when the preprocessor registry didn't set `env.meta.moduleName` (it never does on the strict-mode path), so entries no longer collapse onto a shared placeholder key. - Suffix that key so it doesn't resolve to a real file. A .gjs file's own JS coverage has a real source map, and applying it to template positions read off the pre-compilation AST produced invalid columns and crashed reporting for the whole payload. Fix adjustCoverage discarding coverage on key collision: Two raw keys resolving to the same file overwrote rather than merged, so one silently won. Merges via istanbul-lib-coverage now — the template and JS halves of a .gjs file depend on it, and it was already wrong for any other collision. Standalone CLI: `coverage-merge` bin runs the merge without ember-cli, for projects with no ember-cli command layer. Takes optional --root and --config. New /core subpath export, exposing the config, path-mapping and report utilities without pulling in babel, vite, or testem code.

Add vite support

409aa1e

SergeAstapov commented Jun 18, 2026

View reviewed changes

kategengler reviewed Jun 18, 2026

View reviewed changes

aklkv mentioned this pull request Sep 11, 2026

feat: Vite support, template coverage, and ember-cli decoupling #432

Open


		### v2 Embroider addons (Rollup-based)

		For v2 Embroider native addons based on https://github.com/embroider-build/addon-blueprint blueprint:


		This matches the [ember-addon-blueprint vite.config.mjs](https://github.com/ember-cli/ember-addon-blueprint/blob/main/files/vite.config.mjs):

		```js

Uh oh!

Conversation

SergeAstapov commented Jun 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kategengler left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mcfiredrill commented Jun 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants