What was the resolution of #49 regarding non-digest assets?

[joshjordan]

@rafaelfranca you made a comment here: #49

...but that thread still has a lot of people flowing to it, and they don't know where to go. Your comment doesn't explain what the resolution or plan is, so over two years later, we are still working around this gems like https://github.com/alexspeller/non-stupid-digest-assets

Can you please give us an update, and make sure that thread sees it? Many places on the web about the issue link to that thread.

[rafaelfranca]

There is no update. It is something in our radar but not a priority.

[joshjordan]

That isn't consistent with your previous post:

We already have enough information to think about this issue and in fact we are going to handle it in some way (we already did some improvements on master branch to alleviate the pain)

What are those improvements? How do we take advantage of them?

[rafaelfranca]

The improvements were raising an exception when a non-digest asset is referenced. You don't need to do anything to take advantage of it, it is enabled by default.

[joshjordan]

I see. That is not the behavior we experience on 2.3.3. Even if it were, I do not see how that addresses the problem.

What can a contributor do to make progress on this? You mentioned that it is on the radar but not a priority, which is a good case for a contributor to take on.

[rafaelfranca]

#239

[joshjordan]

That is an open pull request. What can a contributor do to make progress on this?

[joshjordan]

@celsodantas do you understand what the next steps are here?

[rafaelfranca]

It depends which problem are we trying to solve. The problem we are trying to solve is: there is some assets that we don't want to generate digest. But there are people that want: we want to generate a version of each asset in our application that don't have a digest.

We want to solve the first problem, but we don't want to solve the second problem. #49 talks about both. Which problem are you expecting to be solved?

[joshjordan]

I'm really asking what you were talking about when you said:

in fact we are going to handle it in some way

1. Please, tell us what that way is so that we can implement it.
2. Can you explain what your intention was by linking PR adding "nodigest" task to add non digest assets #239?

cc @alexspeller

[rafaelfranca]

The way is #239. But it can be other ways that we still didn't thought about.

[joshjordan]

Then I guess I'll just ask the same question I asked yesterday:

That is an open pull request. What can a contributor do to make progress on this? Why isn't it merged?

[rafaelfranca]

What can a contributor do to make progress on this? Why isn't it merged?

In reality nothing. The value of the feature proposed there and discussed in #49 is still unsure. I'm still evaluating if it is worth the complexity in the library due the fact of removing caching digest will invalidate a core principle of sprockets that is generating assets with digest so they can be cached forever in the CDN.

The use cases still don't justify having support for this built-in in the library. There are alternatives and I believe the rake task presented in #49 (comment) is sufficient for most of the cases.

This is why I asked: which problems do you think removing the digest from the assets will solve?

[joshjordan]

I think there are lots of issues caused here, such as the inability to
refer to static asses from anywhere you don't have the Rails rendering
pipeline. A big use case for this is with rich client apps, which have been
on the rise for years, but are becoming further and further separated from
the web backend. It requires a lot of configuration and diving deep into
the internals of sprockets & rails to get this right for many, many
projects. Another major case is getting applications to communicate with
one another by sharing javascript - this may be internal apps on different
stacks, or serving assets to third party consumers.

However, for me, the largest motivator is for email. Right now, we refer to
a specific version and, by default, those assets are getting cleaned up by
tools like capistrano. In order to keep emails working, you need to do
something special to preserve assets. My problem is that the default state
of the ecosystem is a broken one.

I am not even touching the plethora of people who are simply frustrated by
this because of all the time it cost them, and the inability to do anything
about it without spending hours understanding the problem and figuring out
how to solve it. If the rake task is actually the solution (which I
disagree with), why not include the rake task in sprockets-rails? Tell me:
when a new developer starts using Rails tomorrow, how do we stop him from
ALSO having to understand what is going on in his app, finding thread #49,
and read through the entire thing to find a rake task he has to copy/paste
into his app? That process takes hours - are we really expecting people to
do that?

Data indicates that hundreds of developers over tens of thousands of
projects have disagreed with this approach and have, out of frustration,
monkeypatched their applications to work differently.
https://rubygems.org/gems/non-stupid-digest-assets/versions/1.0.8 Look at
how many folks in #49 are hacking around this and begging for another
solution. The amount of time that's been wasted here is massive. Please,
help us.

On Wed, Apr 27, 2016 at 5:27 PM Rafael França [email protected]
wrote:

What can a contributor do to make progress on this? Why isn't it merged?

In reality nothing. The value of the feature proposed there and discussed
in #49 #49 is still
unsure. I'm still evaluating if it is worth the complexity in the library
due the fact of removing caching digest will invalidate a core principle of
sprockets that is generating assets with digest so they can be cached
forever in the CDN.

The use cases still don't justify having support for this built-in in the
library. There are alternatives and I believe the rake task presented in #49
(comment)
#49 (comment)
is sufficient for most of the cases.

This is why I asked: which problems do you think removing the digest from
the assets will solve?

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#343 (comment)

[rafaelfranca]

why not include the rake task in sprockets-rails?

If the non-stupid-digest-assets gem works why not keeping using it?

Including it in sprockets-rails disabled by default will still require users to understand their problems, so including it in sprockets-rails doesn't solve the knowledge problem.

Including it in sprockets-rails enabled by default will require users that don't need this feature to pay the price. I really don't want to do it.

That said, I personally don't want to do anything about this issue. In my opinion it is already solved by non-stupid-digest-assets and I don't want to maintain a code which I don't use or even agree.

Others may disagree with me and want to implement this feature, it us up to them.

[joshjordan]

The problem is the amount of time it takes for someone to realize that they
need that gem, and then to go out and discover it. Its hours, and they
might not ever find it, and end up hacking around it or just giving up.
Would you accept a PR to put it in the README or documentation?

I don't want to change the default behavior. I just want to give people the
ability to use the framework the way they are trying to use it anyway.

On Wed, Apr 27, 2016 at 5:52 PM Rafael França [email protected]
wrote:

why not include the rake task in sprockets-rails?

If the non-stupid-digest-assets gem works why not keeping using it?

Including it in sprockets-rails disabled by default will still require
users to understand their problems, so including it in sprockets-rails
doesn't solve the knowledge problem.

Including it in sprockets-rails enabled by default will require users that
don't need this feature to pay the price. I really don't want to do it.

That said, I personally don't want to do anything about this issue. In my
opinion it is already solved by non-stupid-digest-assets and I don't want
to maintain a code which I don't use or even agree.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#343 (comment)

[celsodantas]

Should we then update the README for the use case? Maybe pointing to the non-stupid-digest-assets gem. That would solve the knowledge problem.

[jeremy]

Let's stick to the pull request and concrete work. We have a surplus of fully-hashed-out debate on this topic.