-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issues having a file that matches manifest-*.json in your assets directory #229
Comments
Yeah, I'd really like to rename that file. First it should probably be a wdyt? |
👍 for |
The trick is probably going to be transitioning away from the old name. There definitely has to be a good upgrade path here. This 3.x beta seems like a good time. We can probably support both styles on 3.x and only this new one on 4.x. |
Yup, I think that's a good approach, and won't clash with any assets you actually want served. 👍 here as well. |
Cool. I'll probably take a look at this sometime over this weekend. Otherwise, if someone wants to get a PR started sooner, I'm happy to help up and give direction. |
Ah, I just realized this is on the sprockets-rails issue tracker. The change should be made to sprockets core. I'll open a cross referencing issue over there. |
This is fixed at sprockets 3. |
So, we had a JSON manifest we were using for our favicons following this W3C draft - https://w3c.github.io/manifest/ . The file was named
manifest.json
, and was living alongside the icon assets in assets/images.What ends up happening is this file gets precompiled by the asset pipeline, and you now have:
manifest-<some hash>.json
manifest-<some other hash>.json
in your resulting public/assets directory
As best I can tell, when you start the app, whatever
.first
returns from all files that matchmanifest-*.json
is used as the asset pipeline manifest, which ends up causing asset helpers to return paths to uncompiled assets when the wrong manifest is selected. The matcher is extra confusing because even if you renamed that file, saymanifest-favicons.json
, it would still match and exhibit the same behavior.Seems like precompilation should fail when this situation is detected.
(and yeah, we're doing it wrong since static assets should live in /public, but this still seems like a pretty dangerous gotcha)
The text was updated successfully, but these errors were encountered: