Should propshaft always return the latest compiled assets in development?

[yokonao]

Hello! I'm a developer who loves using Propshaft. I find it simple and really like it.
I have a question about its behavior.

I've already read through the discussion at #97.

In development environments, Propshaft is expected to compile and return asset files at request time. This ensures that frequently updated asset files in development are always served in their latest state.

However, there seems to be an exception to this behavior. As mentioned in the warning when running the assets:precompile task, once assets:precompile is executed, Propshaft switches to returning compiled assets, and subsequent on-demand compilation at request time no longer occurs.

I believe this behavior differs from Rails users' expectations. In fact, other developers have had the same concern: #97

Is it intentional design that assets are not compiled in certain situations even in development environments? I think it would be preferable to always return the latest compiled assets. As an alternative, an explicit option to opt-in to static asset serving in development environments would be good.

Note

If we want to always return the latest assets in development, two modifications would be needed:

• The resolver decision logic in Propshaft::Assembly.
• Implementing Propshaft::Server as Rack Middleware to run before ActionDispatch::Static.

[brenogazzola]

The current logic allows developers to both always have updated asset or to always use the precompiled assets.

If we force Propshaft in development to always use the dynamic resolver, we are effectively removing the second option from developers.

Since I explained in #97 how developers who want the 'always get updated assets' can get that behavior with a minor change in a project file they control, it feels to me the current solution produces the best of both worlds.

I'm not saying this can't change, just that right now, with the explanations I have already been given so far, I don't think the upside (less confusion) makes up for the downside (no longer being able to use static assets in development).

[yokonao]

@brenogazzola Thank you for your prompt response!

I find your explanation of the reasoning behind this specification quite convincing in many aspects. However, I would like to respectfully present a counterargument on the following point, as I believe we could provide an alternative solution:

If we force Propshaft in development to always use the dynamic resolver, we are effectively removing the second option from developers.

For example, we could introduce an environment variable like PROPSHAFT_USE_STATIC_ASSETS that, when set, would force the use of static assets. This would allow developers to flexibly choose the asset resolution method based on their specific situation.
My reasoning for this argument is that while "there are indeed cases where developers want to use compiled assets in the development environment, such cases are not particularly frequent." On the other hand, the majority of developers need on-demand compiled assets to be served in the development environment.
Therefore, wouldn't an approach that handles relatively rare cases through an opt-in mechanism while defaulting to on-demand compilation be a better solution that avoids confusion while preserving convenience? (Of course, this is just my opinion as one developer.)

Regarding the solution mentioned in #97 (comment), while it is indeed simple, I believe it's a workaround that only makes sense once you understand Propshaft's operating principles, and it's not intuitive for general developers. Additionally, since the return value of Rails.application.config.assets.manifest_path.exist? can change during server runtime, there's a risk that the resolver might switch at unintended times.

I truly appreciate your thoughtful consideration of this matter.

[theodorton]

Implementing Propshaft::Server as Rack Middleware to run before ActionDispatch::Static.

Just wanted to mention that Rack middleware is already underway:
#249

I believe this behavior differs from Rails users' expectations.

Sprockets worked the same way, prioritizing precompiled assets over fresh assets - so I believe the behaviour is expected for most Rails developers.

[yokonao]

Certainly, if Sporockets also prioritizes precompiled assets, it might be better to align the behavior.
Thank you for letting me know.