-
Notifications
You must be signed in to change notification settings - Fork 72
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
Propshaft detection is load order dependant #151
Comments
xymbol
added a commit
to xymbol/inline_svg
that referenced
this issue
Oct 24, 2023
It fixes jamesmartin#151 by allowing to set the asset finder to a callable object. This is useful when the asset pipeline is not ready when the initializer is run, for example when using Propshaft. I'm not sure if this is the best way to solve this problem. On one hand, Propshaft could be be ready when its initializer is run, but on the other hand, this gem's railtie assumes the asset pipeline is ready.
xymbol
added a commit
to xymbol/inline_svg
that referenced
this issue
Oct 24, 2023
It fixes jamesmartin#151 by allowing to set the asset finder to a callable object. This is useful when the asset pipeline is not ready when the initializer is run, for example when using Propshaft. I'm not sure if this is the best way to solve this problem. On one hand, Propshaft could be be ready when its initializer is run, but on the other hand, this gem's railtie assumes the asset pipeline is ready.
xymbol
added a commit
to xymbol/inline_svg
that referenced
this issue
Oct 24, 2023
It fixes jamesmartin#151 by allowing the asset finder to be a callable object. This is useful when the asset pipeline is not ready when the initializer is run, for example, when using Propshaft. I don't know if this is the best way to solve this problem. On the one hand, Propshaft could be done when its initializer is run, but on the other hand, this gem's railtie assumes the asset pipeline is ready.
xymbol
added a commit
to xymbol/inline_svg
that referenced
this issue
Oct 24, 2023
It fixes jamesmartin#151 by allowing the asset finder to be a callable object. This is useful when the asset pipeline is not ready when the initializer is run, for example, when using Propshaft. I don't know if this is the best way to solve this problem. On the one hand, Propshaft could be done when its initializer is run, but on the other hand, this gem's railtie assumes the asset pipeline is ready.
xymbol
added a commit
to xymbol/inline_svg
that referenced
this issue
Oct 24, 2023
It fixes jamesmartin#151 by allowing the asset finder to be a callable object. This is useful when the asset pipeline is not ready when the initializer is run, for example, when using Propshaft. I don't know if this is the best way to solve this problem. On the one hand, Propshaft could be done when its initializer is run, but on the other hand, this gem's railtie assumes the asset pipeline is ready.
Thank you, this helped me with my Propshaft-based app! Just to help people Googling for this, the error I got when calling |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Propshaft integration works without configuration but depends on the entries'
Gemfile
order. The detection works when theinline_svg
is listed afterpropshaft
.The issue is caused by
inline_svg
determining which adapter to use in anafter_initialize
block and caching its value too early in the boot process when Propshaft is not ready. I found the call here:inline_svg/lib/inline_svg/railtie.rb
Line 19 in 1a1e2e0
Propshaft also uses an
after_initialize
block to finalize its configuration, and Rails keeps track of railties in their load order. That's why swapping the gems is a workaround.A proper fix would be to evaluate
asset_finder
when called and once the assets are ready.The text was updated successfully, but these errors were encountered: