Serve script tags from Vite's development server

[tricknotes]

Summary

include_ember_script_tags always reads the output of ember build, so a Vite-based application served by ember-cli-rails's development server (tricknotes/ember-cli-rails#653) cannot use the asset helpers without opting out of the server with dev_server: false — and with it, out of fast reloads: embedding the app into Rails-owned HTML then requires a full build (8–10 seconds in my measurements) before a change shows up.

When the application is served by the development server, the helper now reads index.html from the server instead of a build directory, and emits the startup tags with root-relative URLs rewritten to absolute URLs on the server — the same rewrite ember-cli-rails applies when it serves the document itself. Nothing is built, so a change to the application is picked up by reloading the page (about 550 ms from change to reflection in my measurements).

Implementation notes

• The development server is feature-detected with app.respond_to?(:dev_server?), so combinations with older ember-cli-rails releases (which have no development server) keep their current behavior. The development dependency stays on the released ember-cli-rails; the examples covering the new path stand in plain doubles for the development-server API until a release carries it.
• The tag extraction shared with the build-directory path is factored into vite_startup_tags(html, prefix:). It now also leaves protocol-relative (//) URLs alone.
• include_ember_stylesheet_tags raises its Vite guidance for development-server applications too: their dist may not exist, so the Vite detection alone would miss them.
• CHANGELOG.md carries the new behavior under an Unreleased section.

Verification

• Added helper specs for the new path (URL rewriting, absolute and protocol-relative URLs passed through, the stylesheet-helper error). spec/helpers and spec/lib pass against the released ember-cli-rails: 11 examples, 0 failures.
• The 3 spec/features examples fail in my environment for browser-setup reasons, identically with and without this change (verified against a baseline), so please rely on CI for them.
• Verified end to end in a host Rails application: a page whose HTML is owned by Rails emits tags pointing at the development server, the Ember app boots, and a change to app/styles/app.css is served after a plain reload.

🤖 Generated with Claude Code