Skip to content
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

Closed
sedubois opened this issue Mar 2, 2022 · 9 comments
Closed

Hard dependency on Sprockets prevents migration to Propshaft #2151

sedubois opened this issue Mar 2, 2022 · 9 comments
Labels
bug breakages in functionality that is implemented

Comments

@sedubois
Copy link
Contributor

sedubois commented Mar 2, 2022

  • What were you trying to do?

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.

  • What did you end up with (logs, or, even better, example apps are great!)?

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 empty app/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 from app/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.

  • What versions are you running?
    • Rails 7.0.2.2
    • administrate 0.17.0 rev 3b2413a
@sedubois sedubois added the bug breakages in functionality that is implemented label Mar 2, 2022
@sedubois sedubois changed the title Administrate has a hard dependency on Sprockets Hard dependency on Sprockets prevents migration to Propshaft Mar 2, 2022
@nickcharlton
Copy link
Member

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?

@sedubois
Copy link
Contributor Author

sedubois commented Mar 2, 2022

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:

  • importmaps are the new default in Rails apps, but I've been having issues with them
  • so I moved to jsbundling-rails/esbuild to solve these issues
  • but this leads to apparently sourceMaps not working when using Sprockets
  • because of this, our JS crash reports don't have proper stack traces
  • so I experimented migrating to Propshaft, which is described as not yet fully stable but the successor to Sprockets nevertheless
  • this first requires moving CSS bundling from Sprockets to cssbundling-rails, however it seems to have issues with vendored Sass stylesheets
  • and propshaft is incompatible with Administrate, hence this issue report

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.

@sedubois
Copy link
Contributor Author

sedubois commented Mar 3, 2022

@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 (@hotwired/stimulus). So a solution might be to publish an administrate node package with the relevant assets. I guess this should work for both JS and CSS. Or maybe something is possible with engines, which I know nothing about...

(NB: There is a stimulus-rails gem which does directly provide JS files, but they seem only usable when using Sprockets. Otherwise, all the gem apparently does is provide a few view helpers plus a rails stimulus:install task to install a reference to the node package in either the importmap or the package.json.)

@nickcharlton
Copy link
Member

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.

@brunoprietog
Copy link

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.

@adam-majkowski
Copy link

@sedubois did you succeed in making administrate work with propshaft? We are facing the same problem in our application

@sedubois
Copy link
Contributor Author

@adam-majkowski no, I didn't get back to using propshaft, in part because of this blocker.

@nickcharlton nickcharlton mentioned this issue Jan 20, 2023
3 tasks
@vpereira
Copy link

I'm just having to drop administrate because of hard requirement on sprockets.

@nickcharlton
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug breakages in functionality that is implemented
Projects
None yet
Development

No branches or pull requests

5 participants