⚒ 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.

Behaviors are classes that have a .trigger class method.

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

DeprecationToolkit::Behaviors::Raise will raise either:
- DeprecationToolkit::DeprecationIntroduced error if a new deprecation is introduced.
- DeprecationToolkit::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 separated 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 class and perform the logic you want. Your behavior needs to respond to .trigger.

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

DeprecationToolkit::Configuration.behavior = StatsdBehavior

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 behaviour 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.

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

License

Deprecation Toolkit is licensed under the MIT license.

stanhu/deprecation_toolkit