-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Hard dependency on Sprockets prevents migration to Propshaft #2151
Comments
Thanks for opening this! Yeah, I was suspecting this might be the case. I'm not sure if we can (or maybe I mean should?) do anything about this until some other asset changes are done (I'm thinking of #2148, or an equivalent at least). Do you have any thoughts on how we might be able to support both? |
At this point I haven't had thoughts on the solution on the administrate side as I'm really not familiar with the Rails asset pipeline. Just some background on how I got here:
So I'm blocked by these two last points from using Propshaft, meaning that we currently seem stuck with hard to interpret JS crash reports. |
@nickcharlton If I take the example of Stimulus (which is now part of the default Rails 7 stack), it's provided as a node package ( (NB: There is a |
Thanks! That's helpful. I think our eventual solution here is going to be to split it into an npm package too. I've been thinking about how to update in such a way to support all of the asset handling approaches and I suspect this is the only way. |
It is not necessary to publish it as a package. In fact, the javascript files that include stimulus-rails or turbo-rails are used in importmap. Propshaft does recognize those files and they remain in the assets. Even actiontext, actioncable, activestorage, etc, do the same. You can see it in the importmap configuration file that Rails 7 generates by default when creating a new app. |
@sedubois did you succeed in making |
@adam-majkowski no, I didn't get back to using propshaft, in part because of this blocker. |
I'm just having to drop administrate because of hard requirement on sprockets. |
I'm going to close this we've just merged in #2397, which will mean that in future release we'll be bundling assets in the Administrate Gem and so we've been able to drop any dependencies on assets from those using the gem. I'm going to start releasing some pre-release versions of the gem in the coming days, as I'm sure I'm about to break stuff for people, and so we can get feedback and make sure there's nice migration help sorted out. |
I am following the Propshaft upgrade guide. After replacing Sprockets with Propshaft in my Gemfile, I expect Sprockets-related errors to disappear and Administrate views to render correctly.
Sprockets is still invoked as it's a transitive gem dependency of Administrate, leading to
Sprockets::Railtie::ManifestNeededError: Expected to find a manifest file in app/assets/config/manifest.js
. As a workaround, an emptyapp/assets/config/manifest.js
file can be kept.However then, I get the error
Propshaft::MissingAssetError
:The asset 'administrate/application.css' was not found in the load path
which appears to come fromapp/views/administrate/application/stylesheet.html.erb
.It looks like propshaft and sprockets do not play along each other nicely, and Administrate should support working with Propshaft, otherwise it prevents applications from migrating.
The text was updated successfully, but these errors were encountered: