Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/Shopify/deprecation_toolkit

⚒Eliminate deprecations from your codebase ⚒
https://github.com/Shopify/deprecation_toolkit

deprecations gem-upgrade testing

Last synced: about 1 month ago
JSON representation

⚒Eliminate deprecations from your codebase ⚒

Awesome Lists containing this project

README 

        
# ⚒ 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](https://www.youtube.com/watch?v=20pj_ajDBOg).

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)

```sh

rails test  -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.



```ruby

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.



```ruby

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



```ruby

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



```ruby

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.



```ruby

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:



```ruby

DeprecationToolkit::Configuration.warnings_treated_as_deprecation = [//]

```



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



```ruby

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`



```ruby

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.



```ruby

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.



```ruby

DeprecationToolkit::Configuration.test_runner = :rspec

```



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



```ruby

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



```sh

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

```



## License



Deprecation Toolkit is licensed under the [MIT license](LICENSE.txt).