⚒ Deprecation Toolkit ⚒

Introduction

Deprecation Toolkit is a gem that helps you get rid of deprecations in your codebase. Having deprecations in your application usually means that something will break whenever you upgrade third-party dependencies. The sooner the better to fix them! Fixing all deprecations at once might be tough depending on the size of your app and the number of deprecations. You might have to progressively resolve them while making sure your team doesn't add new ones. This is where this gem comes handy!

How it works

The Deprecation Toolkit gem works by using a shitlist approach. First, the gem records all existing deprecations into .yml files. When running a test that have non-recorded deprecations after the initial recording, Deprecation Toolkit triggers a behavior of your choice (by default it raises an error).

Recording Deprecations

As said above, the Deprecation Toolkit works by using a shitlist approach. You have two ways to record deprecations. Either set DeprecationToolkit::Configuration.behavior to DeprecationToolkit::Behaviors::Record (see the Configuration Reference below) Or run your tests with the --record-deprecations flag (or simply the -r shortcut)

rails test <path_to_my_test.rb> -r

Configuration Reference

🔨 #DeprecationToolkit::Configuration#deprecation_path

You can control where recorded deprecations are saved and read from. By default, deprecations are recorded in the test/deprecations folder.

The deprecation_path either accepts a string or a proc. The proc is called with the path of the running test file.

DeprecationToolkit::Configuration.deprecation_path = 'test/deprecations'
DeprecationToolkit::Configuration.deprecation_path = -> (test_location) do
  if test_location == 'admin_test.rb'
    'test/deprecations/admin'
  else
    'test/deprecations/storefront'
  end
end

🔨 #DeprecationToolkit::Configuration#behavior

Behaviors define what happens when non-recorded deprecations are encountered.

This gem provides 4 behaviors, the default one being DeprecationToolkit::Behaviors::Raise.

• DeprecationToolkit::Behaviors::Raise will raise either:
  • DeprecationToolkit::Behaviors::DeprecationIntroduced error if a new deprecation is introduced.
  • DeprecationToolkit::Behaviors::DeprecationRemoved error if a deprecation was removed (compare to the one recorded in the shitlist).
• DeprecationToolkit::Behaviors::Record will record deprecations.
• DeprecationToolkit::Behaviors::CIRecordHelper See separate explanation below.
• DeprecationToolkit::Behaviors::Disabled will do nothing.
  • This is useful if you want to disable this gem for a moment without removing the gem from your Gemfile.

DeprecationToolkit::Configuration.behavior = DeprecationToolkit::Behaviors::Record

You can also create your own behavior object and perform the logic you want. Your behavior needs to respond to trigger.

class StatsdBehavior
  def trigger(test, deprecations, recorded_deprecations)
     # Could send some statsd event for example
  end
end

DeprecationToolkit::Configuration.behavior = StatsdBehavior.new

DeprecationToolkit::Behaviors::CIRecordHelper

This is a special type of behaviour meant to help you record deprecations if you have a lof of them. Imagine if you have thousands of tests and need to record deprecations for each on your machine, this is going to take ages. Recording deprecations on CI with the regular Record behavior isn't possible because of the way CI parallelize test in multiple container (Multiple tests from the same file runs in parallel in diferrent machines, the deprecation files that get created are then splitted. Regrouping them is a nightmare.)

This behavior will output a JSON representation of your deprecations. Your CI should have a way to download the log generated from the test run. Download it on your locale machine. Finally run the rake task FILEPATH=<path_to_downloaded_log> deprecation_toolkit:record_from_ci_output. This task will parse your CI log and grab the output generated by the DeprecationToolkit and will finally convert everything back to YML files.

🔨 #DeprecationToolkit::Configuration#allowed_deprecations

You can ignore some deprecations using allowed_deprecations. allowed_deprecations accepts an array of Regexp and Procs.

Whenever a deprecation matches one of the regex, it is ignored.

DeprecationToolkit::Configuration.allowed_deprecations = [/Hello World/]

ActiveSupport::Deprecation.warn('Hello World') # ignored by Deprecation Toolkit

When passing procs, each proc will get passed the deprecation message and the callstack. This is useful if you want to whitelist deprecations based on the caller.

DeprecationToolkit::Configuration.allowed_deprecations = [
  ->(message, stack) { message ~= 'Foo' && stack.first.label == 'method_triggering_deprecation' }
]

def method_triggering_deprecation
  ActiveSupport::Deprecation.warn('Foo') # Ignored by the the DeprecationToolkit
end

🔨 #DeprecationToolkit::Configuration#warnings_treated_as_deprecation

Most gems don't use ActiveSupport::Deprecation to deprecate their code but instead just use Kernel#warn to output a message in the console.

Deprecation Toolkit allows you to configure which warnings should be treated as deprecations in order for you to keep track of them as if they were regular deprecations.

This setting accepts an array of regular expressions. To match on all warnings, you can provide a empty regex:

DeprecationToolkit::Configuration.warnings_treated_as_deprecation = [//]

In addition to regexps, anything that responds to === can be a matcher, for instance a proc:

DeprecationToolkit::Configuration.warnings_treated_as_deprecation = [
  ->(warning) { !warning.match?(/not a deprecation/)}
]

🔨 #DeprecationToolkit::Configuration#deprecation_file_path_format

DeprecationToolkit allows you to choose the file path format for deprecation files.

For Minitest, it defaults to using class name so the following code would correspond to #{deprecation_path}/deprecation_toolkit/behaviors/raise_test.yml

module DeprecationToolkit
  module Behaviors
    class RaiseTest < ActiveSupport::TestCase
    end
  end
end

For rspec if defaults to the file location with spec removed. /spec/models/user_spec.rb would correspond to /models/user.yml.

If you have a specific use case you can configure this with a custom format using a proc. The proc is called with an instance of the test.

Configuration.deprecation_file_path_format = -> (test) do
  Kernel.const_source_location(test.class.name)[0].sub(%r{^./test/}, "").sub(/_test.rb$/, "")
end

RSpec

By default Deprecation Toolkit uses Minitest as its test runner. To use Deprecation Toolkit with RSpec you'll have to configure it.

DeprecationToolkit::Configuration.test_runner = :rspec

Also make sure to require the before/after hooks in your spec_helper.rb or rails_helper.rb.

require "deprecation_toolkit/rspec"

It's possible to record deprecations while running your specs by adding an ENV['DEPRECATION_BEHAVIOR'] variable to your test run. Run your specs with this ENV set to "record-deprecations", "record" (or simply the "r" shortcut).

DEPRECATION_BEHAVIOR="record" bundle exec rspec path/to/file_spec.rb

Usage without Rails

Without Rails, you'll need to make sure your ActiveSupport::Deprecation instances use the :notify behavior and the attach_to is the underscored version of the deprecator's gem_name (this is how the :notify behavior works):

# defined in the gem:
MyGem.deprecator = ActiveSupport::Deprecation.new("2.0", "MyGem::Something")

# in the test helper:
MyGem.deprecator.behavior = :notify

DeprecationToolkit::Configuration.configure do |config|
  config.attach_to = MyGem.deprecator.gem_name.underscore.tr("/", "_")
  # or more simply
  # config.attach_to = "my_gem_something"
  config.behavior = :notify
end

License

Deprecation Toolkit is licensed under the MIT license.