Precompile with regex does not work

[schneems]

When you add this to your precompile

config.assets.precompile << %r(bootstrap/glyphicons-halflings-regular\.(?:eot|svg|ttf|woff2?)$)

The regex gets passed directly to sprockets, and sprockets doesn't know what to do with it so it blows up.

This was reported in rails/sprockets#117. This worked in sprockets-rails 2.3.2 and fails in version 3.0.0.beta2 (commit e65e088).

[Andreis13]

Sprockets 3.0.0 deprecated precompile filters such as regexps and procs, thus sprockets-rails requires the user to specify the files that are to be compiled in a manifest file (assets/manifest.js) through the use of link and link_tree directives.

[schneems]

We need to make that clear. We should go through a deprecation cycle (warn in one 2.x release and remove in the 3.x release). Once out, we should make the interface explicit by raising a helpful error message if invalid input is provided. We can't rip it out with no warning.

[Andreis13]

Actually Sprockets 3 still supports these filters but the functionality is provided by a legacy.rb file (which is removed from Sprockets 4).

Sprockets-rails works with both approaches but I agree that we could add some kind of warnings on this level to prevent the old method.

[schneems]

Ahh, okay. I kinda inherited sprockets 😁 i'm still discovering dusty corners.

Instead of actually printing out any deprecation notices, the sprockets legacy.rb added a code comments:

    # Deprecated: Change default return type of resolve() to return 2.x

ಠ_ಠ

We should probably deprecate in sprockets-rails (high level for a nicer error message) and in Sprockets 3 as well. Do you have any idea where this behavior actually comes from in sprockets?

[Andreis13]

I also dived into Sprockets not so long ago, so I might be wrong about this, but from my point of view there are a couple of issues concerning the separation of responsibility between sprockets and sprockets-rails. I think the precompile assets list is one of them. Logically, sprockets-rails is the one which should keep track of assets that must be compiled and of them being listed somewhere. However, the use of filters required them to be compiled into uniform lambdas, and the functionality for this was placed in sprockets. As a result this thing was scattered between two gems. Lately it was decided to move away from filters and give way to manifests because these might provide greater benefits and a uniform interface for ES6 modules, as I understand.

Once again, I might be wrong about this :)

[schneems]

That's the fun part, I have no historical context (^_^)/. That sounds reasonable.

I re-opened the sister issue. I'll take a look into deprecating things there in a bit.

[icecold21]

This issue has been fixed in this commit, but it's still in branch master.

FortAwesome/font-awesome-sass@b8dd32c

[ferydjzz]

+1 for @icecold21