Sprockets

Registered the new map and near-me scripts on the existing asset manifest so they could ship without a JavaScript bundler. The pages then linked those assets from the layout.

What worked

Adding the files to the manifest matched the current pipeline. No compile failure showed up while the pages and tests were being written.

The chat loader and styles were added to the existing Sprockets bundles rather than a module bundler. Test renders compiled those assets, and the order page included the chat script the assertions checked.

What worked

New JavaScript and CSS were picked up by the current asset pipeline and showed up in the rendered page without extra build tooling.

Sprockets 4 served the order-page scripts, including the Action Cable browser build pulled in from the gem. I was unsure the UMD wrapper and modern syntax would survive concatenation, so I read the asset and the pipeline behavior before relying on it. A compiled lookup then showed the consumer and the channel name present in the application bundle. The later hosted-chat page script went through the same pipeline without a compile error.

What worked

Requiring the library asset from the gem resolved to the shipped JavaScript, and the compiled bundle contained the APIs the page needed.

What got in the way

It was not obvious from the pipeline alone whether modern syntax inside a UMD file would be left intact. That had to be checked in the gem source and by compiling.

Chat styles and the browser bootstrap were added to the existing Sprockets 4 pipeline. The test run compiled those assets. The page loads the chat vendor script from a tag because this pipeline serves the app script as written.

What worked

Asset compilation during the test run succeeded, and the order page could include the chat markup and script without a separate bundler.

Registered the pickup map script and vendored map library with the Sprockets 4 asset pipeline so server-rendered pages could load them. Image files had to sit where relative stylesheet URLs would resolve. Compiled assets were served, and listing HTML included the map library.

What worked

After files were placed in the pipeline, the running app served script and stylesheet references without a separate front-end build.

What got in the way

Relative image URLs in the third-party stylesheet resolved only after images were vendored where the pipeline expects them.

The project had no JavaScript bundler at all, only this asset pipeline wired to stylesheets. Added a small vanilla script by creating the directory, adding a manifest link line, and referencing it from the layout, then confirmed by booting the app and resolving the asset through the pipeline.

What worked

Adding one script needed three small edits and no toolchain. Asset resolution can be checked programmatically at boot, which gave a definitive yes rather than guessing from a page load. For a project with no bundler, this was the lowest-risk way to add behavior.

What got in the way

The manifest linking model is the part most likely to be gotten wrong silently: a missing link line yields a file that simply does not resolve, with no build-time complaint. Knowing which directories are on the load path required inspecting runtime configuration rather than reading a config file.

The existing Sprockets manifest and application assets were extended for the map, and the production asset precompile completed successfully.

What worked

It accommodated the new map assets without adding a JavaScript bundler or external build service.

The app's only front-end tooling was this classic pipeline — no bundler, no package manifest. I added a new script and stylesheet rules through it and verified they precompiled under production settings before considering the work done.

What worked

For plain files it is dependency-free and does the job: add the file, link it in the manifest, and it precompiles and fingerprints correctly. The clobber task cleaned build output completely. Having no Node toolchain at all is genuinely simpler to reason about for a small amount of JS.

What got in the way

It has no concept of modern module resolution, which constrained the whole design — the third-party client had to come from a CDN as a native module rather than being bundled. Forgetting to link a new file in the manifest produces no error in development and only fails in production where runtime compilation is off; catching that required deliberately running a production-mode precompile.

Sprockets packaged the new consent-aware browser tracking through the application's existing asset manifest. A production precompile succeeded, confirming that the JavaScript and stylesheet additions were discoverable and buildable.

What worked

The existing manifest needed only a small update, and the production build completed without an asset-pipeline error.

Extended the asset manifest for a new JavaScript entry point, then precompiled and clobbered generated assets through Rails tasks. Compilation succeeded, and cleanup removed build artifacts before handoff.

What worked

The existing no-build-step asset pipeline handled the assistant's JavaScript and CSS without adding a frontend bundler.

What got in the way

The repository initially lacked the JavaScript directory linkage needed by the new asset, so the manifest required an explicit update.