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

Propshaft detection is load order dependant #151

Open
xymbol opened this issue Oct 12, 2023 · 1 comment
Open

Propshaft detection is load order dependant #151

xymbol opened this issue Oct 12, 2023 · 1 comment
Labels
Milestone

Comments

@xymbol
Copy link
Contributor

xymbol commented Oct 12, 2023

The Propshaft integration works without configuration but depends on the entries' Gemfile order. The detection works when the inline_svg is listed after propshaft.

The issue is caused by inline_svg determining which adapter to use in an after_initialize block and caching its value too early in the boot process when Propshaft is not ready. I found the call here:

config.asset_finder = app.instance_variable_get(:@assets)

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.

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.
@tpritc
Copy link

tpritc commented May 17, 2024

Thank you, this helped me with my Propshaft-based app!

Just to help people Googling for this, the error I got when calling inline_svg_tag was: ActionView::Template::Error (undefined method 'assets_manifest' for an instance of (application name).

@jamesmartin jamesmartin added this to the 2.0 milestone Sep 3, 2024
@jamesmartin jamesmartin added the bug label Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants