• Stars
    star
    260
  • Rank 157,189 (Top 4 %)
  • Language
    Ruby
  • License
    MIT License
  • Created about 10 years ago
  • Updated over 8 years ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Easily add custom warnings and errors to your Xcode project's build process

Gem Version Build Status

Easily add custom warnings and errors to your Xcode project's build process

Installation

$ gem install mayday

Usage

Create a Maydayfile

$ mayday init

Add some warning and error checks to that file

# Maydayfile

# Required
xcode_proj "CoolApp.xcodeproj"

# Use regular expressions to define errors or warnings on a line-by-line basis
error_regex "Please remove Copyright boilerplate", /^\/\/  Copyright \(c\).*$/, :files => "*AppDelegate*"
warning_regex "TODO", /^\/\/\s+TODO:.*$/

You can do more advanced checks, too, with blocks

# Maydayfile

warning :line, :exclude => "Fixtures/SomeDir/Excluded/*" do |line|
  line.length > 120 ? "Length of line #{line.length} is longer than 120 characters!" : false
end

# You can get the whole file, too
error :file do |entire_file|
  max_number_of_lines = 500
  
  number_of_code_or_comment_lines = entire_file.split("\n").select { |line| line.strip.length > 0 }.count
  if number_of_code_or_comment_lines > max_number_of_lines
    # Map line numbers to errors
    { "1" => "File is #{number_of_code_or_comment_lines} lines long" }
  else
    false
  end
end

When you're ready, run

$ mayday

Next time you build your project, your errors and warnings will be flagged

Mayday warnings and errors in Xcode

Mayday warnings and errors in Xcode, inline

You can also run mayday from the command line

$ mayday run

You also have the option to choose the file specifying the project and rules (by default this will be Maydayfile) using

$ mayday run --rules MyRulesFile

Since Ruby is installed by default on OSX, the warnings and errors will work for anybody building your project, even if they don't have RVM, RubyGems, or mayday.

Options

warning, error, warning_regex, and error_regex all accept an options hash with any of the following options

  • language limits to files in the provided language. Accepts "swift" and "objective-c".
    • warning :line, :language => "swift" do ...
  • files limits to files that have an absolute path that matches the provided globs. Accepts an array.
    • warning_regex "Foo!", /^barbaz$/, :files => ["*.h"] do ...
  • exclusions doesn't run on files that have an absolute path that matches the provided globs. Accepts an array.
    • warning :line, :exclude => ["*/Pods/*"] do ... Note, Pods are excluded by default by mayday

Cookbook

For some ideas on how to start using mayday, see the cookbook

Benchmarking

You may be concerned about how much overhead this will add to your build process. To see how quickly your mayday checks execute, use

$ mayday benchmark

Caveats

  • mayday uses sourcify to write your custom warning and errors blocks to a build phase, all gotchas in sourcify apply to your blocks.
  • mayday copies your custom blocks, line for line, into a build phase, so all variables inside of them must be of local scope. Anything defined outside of a custom block will not be included in the build phase.
  • Gems cannot be used inside of custom blocks, only vanilla, system Ruby.
  • If your custom blocks have errors in them that aren't found until they're executed (which is done whenever you call mayday), the stack trace won't be very helpful in debugging (because there is no source map from the build phase back to your Maydayfile code)
  • Generating efficient code to write into the build phase is difficult. The code generated by MayDay::ScriptGenerator#to_ruby could definitely be optimized.

Uninstallation

$ mayday down

Contributing

We'd love to see your ideas for improving this library! The best way to contribute is by submitting a pull request. We'll do our best to respond to your patch as soon as possible. You can also submit a new GitHub issue if you find bugs or have questions. :octocat:

Please make sure to follow our general coding style and add test coverage for new features!