You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Frustratingly you may need to use both `register_engine` to get the behavior your want in Sprockets 3 even if you're using the new API (i.e. `register_transformer` etc.). I think this is because the different APIs have a different backend but I haven't looked into it enough to know exactly why they diverged.
Here's a PR that shows the problem: sass/sassc-rails#65
If you only call `register_transformer` then the Sprockets 3 tests will fail. I think this is because the processor built into `lib/sprockets.rb` and registered via `register_engine` still gets executed. By registering the sassc processor again with `register_engine` we're writing over the built in processor to ensure ours takes priority. I'm not 100% on this cause but it seems reasonable.
This PR introduces a way to silence the deprecation for `register_engine` so that libraries that still need the `register_engine` API to function correctly (such as sassc-rails) can operate without deprecations. This is an opt-in flag, we assume if you use the flag that you're aware of the new API and have updated your library appropriately.
After this PR I'm going to change the docs to show how to use both `register_transformer` and `register_engine` at the same time.
Deprecation.new([caller.first]).warn("`register_engine` is deprecated please register a mime type and use `register_compressor` or `register_transformer`")
54
+
unlessoptions[:silence_deprecation]
55
+
msg=<<-MSG
56
+
Sprockets method `register_engine` is deprecated.
57
+
Please register a mime type using `register_mime_type` then
58
+
use `register_compressor` or `register_transformer`.
0 commit comments