lighthouse-matchers 1.0.0 → 1.0.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: f51726040b980a9839d9d977ed5c4d33970143487d99e45a232b14ed1285f676
-  data.tar.gz: 76d4e7ebca933f34aca2493b3a7b2835f3ad40eb2e7e85c9941edf34cd612556
+  metadata.gz: fa3cc9c2c57e0dae4e2ebb61d281a094354514473b4ff20ed8e6abf67e9991e9
+  data.tar.gz: 42c1681ad2022e0dc875f715128e14acf3e1fbeffd4755165979796a69da1840
 SHA512:
-  metadata.gz: bf67b535c041abfd96e076e785b427591c0a6deed1b0c0143ba59ef3925d6ee0da5c2908482fe09ecc2509c1d13b77c8e919da1d394305868dadf59cfe969e91
-  data.tar.gz: fd2c2314d4c48911b64b664580a71b26c7296af56053dba9c904bb68f6406039acaa8d98bc7870c77dc428c36a58ee30c062c2a9ec062de0745e4f75eca06a89
+  metadata.gz: be9ce6e8dae7d79907120bc5b0a9f52aec74efb33c10cade08320996f82817ec9e51b118b4335e5d8cb3a1e307df83dfbc236980cb7d59a4bf8fd718310d8ad9
+  data.tar.gz: af2742c37727f20e3813e72d178c3d19acb0e660063476060b3b290243c71c38d6b7ccf9b579bc3344bc8a0e6b3ed4b4d7dd5eddcd9dd5a6fd009424138fe22b

data/CHANGELOG.md

@@ -0,0 +1,15 @@
+# Changelog
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [1.0.0] - 2019-05-24
+### Added
+- Initial version release with minimal viable matcher
+
+## [1.0.1] - 2019-05-24
+### Changed
+- Apply bug fixes based on integration with a Ruby on Rails project

data/CODE_OF_CONDUCT.md

@@ -0,0 +1,76 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, sex characteristics, gender identity and expression,
+level of experience, education, socio-economic status, nationality, personal
+appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at open-source@ackama.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

data/CONTRIBUTING.md

@@ -0,0 +1,153 @@
+# Contributing 
+
+Although we are always happy to make improvements, we also
+welcome changes and improvements from the community!
+
+Have a fix for a problem you've been running into or an idea for a new feature
+you think would be useful? Here's what you need to do:
+
+1. [Read and understand the Code of Conduct](#code-of-conduct).
+1. Fork this repo and clone your fork to somewhere on your machine.
+1. [Ensure that you have a working environment](#setting-up-your-environment).
+1. Read up on the [architecture of the gem](#architecture), [how to run
+   tests](#running-tests), and [the code style we use in this
+   project](#code-style).
+1. Cut a new branch and write a failing test for the feature or bugfix you plan
+   on implementing.
+1. [Make sure your branch is well managed as you go
+   along](#managing-your-branch).
+   API](#documentation).
+1. [Refrain from updating the changelog.](#changelog)
+1. Push to your fork and submit a pull request.
+1. [Ensure that the test suite passes on Travis and make any necessary changes
+   to your branch to bring it to green.](#continuous-integration)
+
+Although we maintain this gem in our free time, we try to respond to
+contributions in a timely manner. Once we look at your pull request, we may give
+you feedback. For instance, we may suggest some changes to make to your code to
+fit within the project style or discuss alternate ways of addressing the issue
+in question. Assuming we're happy with everything, we'll then bring your changes
+into master. Now you're a contributor!
+
+---
+
+## Code of Conduct
+
+If this is your first time contributing, please read the [Code of Conduct]. We
+want to create a space in which everyone is allowed to contribute, and we
+enforce the policies outline in this document.
+
+[Code of Conduct]: https://github.com/ackama/lighthouse-matchers/blob/master/CODE_OF_CONDUCT.md
+
+## Setting up your environment
+
+The setup script will install all dependencies necessary for working on the
+project:
+
+```bash
+bin/setup
+```
+
+## Architecture
+
+This project follows the typical structure for a gem: code is located in `lib`
+and tests are in `spec`.
+
+There are other files in the project, of course, but these are likely the ones
+you'll be most interested in.
+
+### Tests
+
+In addition, tests are broken up into two categories:
+
+* Unit tests — low-level tests for individual matchers (you're probably
+  interested in these). These tests typically stub out actual requests to the Lighthouse CLI.
+* Integration tests — high-level tests to ensure that the gem works against the CLI tool. These tests are not updated frequently but are important to make sure that changes to the CLI interface do not cause this library to break.
+
+Our approach to testing tends to iterate over time. The best approach for writing tests is to copy an existing test in the same file as where you want to add a new test. We may suggest changes to bring the tests in line with 
+our current approach.
+
+## Code style
+
+We follow a derivative of the [unofficial Ruby style guide] created by the
+Rubocop developers. You can view our Rubocop configuration [here], but here are
+some key differences:
+
+* We allow longer blocks in spec files. This is because `RSpec.describe` blocks can 
+  quite easily go over the default Rubocop limit.
+* We have increased the maximum line length to 100 characters.
+
+[unofficial Ruby style guide]: https://github.com/rubocop-hq/ruby-style-guide
+[here]: .rubocop.yml
+
+## Running tests
+
+### Unit tests
+
+Unit tests are the most common kind of tests in the gem. They exercise matcher
+code file by file using mocked results from the Lighthouse CLI.
+
+To run a unit test, you might say something like:
+
+```bash
+bundle exec rspec spec/lighthouse/matchers/rspec_spec.rb
+```
+
+### Integration tests
+
+The integration tests exercise matchers using real Lighthouse audit results. We aim to 
+select reasonably complex well-known projects that are know to have good audit scores to exercise
+that our matchers correctly catch pass and fail conditions.
+
+To run an integration test, you might say something like:
+
+```bash
+bundle exec rspec spec/integration/lighthouse_matchers_spec.rb
+```
+
+### All tests
+
+In order to run all of the tests, simply run:
+
+```bash
+bundle exec rake
+```
+
+## Managing your branch
+
+* Use well-crafted commit messages, providing context if possible.
+* Squash "WIP" commits and remove merge commits by rebasing your branch against
+  `master`. We try to keep our commit history as clean as possible.
+
+## Documentation
+
+As you navigate the codebase, you may notice certain classes and methods that
+are prefaced with inline documentation. 
+
+If your changes end up extending or updating the API, it helps greatly to update the 
+docs at the same time for future developers and other readers of the source code.
+
+## A word on the changelog
+
+You may also notice that we have a changelog at [CHANGELOG.md](CHANGELOG.md)
+You may be tempted to include changes to this in your branch, but don't worry
+about this — we'll take care of it when we release a new version.
+
+## Continuous integration
+
+While running `bundle exec rake` is a great way to check your work, this command
+will only run your tests against the latest supported Ruby and Rails version.
+Ultimately, though, you'll want to ensure that your changes work in all possible
+environments. We make use of [Travis][travis] to do this work for us. Travis
+will kick in after you push up a branch or open a PR. It takes a few minutes to
+run a complete build, which you are free to
+[monitor as it progresses][travis-project].
+
+[travis-project]: https://travis-ci.org/ackama/lighthouse-matchers
+
+What happens if the build fails in some way? Don't fear! Click on a failed job
+and scroll through its output to determine the cause of the failure. You'll want
+to make changes to your branch and push them up until the entire build is green.
+It may take a bit of time, but overall it is worth it and it helps us immensely!
+
+[travis]: https://travis-ci.org/

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    lighthouse-matchers (1.0.0)
+    lighthouse-matchers (1.0.1)
 
 GEM
   remote: https://rubygems.org/

data/README.md

@@ -1,4 +1,4 @@
-# Lighthouse Matchers [![Maintainability](https://api.codeclimate.com/v1/badges/2f1df198307f6a0489fc/maintainability)](https://codeclimate.com/github/ackama/lighthouse-matchers/maintainability) [![Build Status](https://travis-ci.org/ackama/lighthouse-matchers.svg?branch=master)](https://travis-ci.org/ackama/lighthouse-matchers)
+# Lighthouse Matchers [![Gem Version](https://badge.fury.io/rb/lighthouse-matchers.svg)](https://badge.fury.io/rb/lighthouse-matchers) [![Maintainability](https://api.codeclimate.com/v1/badges/2f1df198307f6a0489fc/maintainability)](https://codeclimate.com/github/ackama/lighthouse-matchers/maintainability) [![Build Status](https://travis-ci.org/ackama/lighthouse-matchers.svg?branch=master)](https://travis-ci.org/ackama/lighthouse-matchers) 
 
 Lighthouse Matchers provides single-line RSpec matchers for 
 expectations against the result of [Lighthouse](https://developers.google.com/web/tools/lighthouse/) 

data/lib/lighthouse/matchers.rb

@@ -20,11 +20,11 @@ module Lighthouse
       end
 
       def lighthouse_cli
-        @lighthouse_cli ||= lighthouse_cli
+        @lighthouse_cli ||= guess_lighthouse_cli
       end
 
       def runner
-        @runner ||= Kernel.method(:system)
+        @runner ||= proc { |cmd| `#{cmd}` }
       end
 
       private

data/lib/lighthouse/matchers/rspec.rb

@@ -11,8 +11,7 @@ RSpec::Matchers.define :pass_lighthouse_audit do |audit, score: nil|
     runner = Lighthouse::Matchers.runner
 
     url = target.respond_to?(:current_url) ? target.current_url : target
-    opts = "'#{url}' --quiet --output=json"
-    opts << " --port '#{port}'" if port
+    opts = "'#{url}' --quiet --output=json #{"--port=#{port}" if port}".strip
     cmd = Lighthouse::Matchers.lighthouse_cli
     output = runner.call("#{cmd} #{opts}")
     results = JSON.parse(output)

data/lib/lighthouse/matchers/version.rb

@@ -2,6 +2,6 @@
 
 module Lighthouse
   module Matchers
-    VERSION = '1.0.0'
+    VERSION = '1.0.1'
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: lighthouse-matchers
 version: !ruby/object:Gem::Version
-  version: 1.0.0
+  version: 1.0.1
 platform: ruby
 authors:
 - Josh McArthur on behalf of Ackama
@@ -77,6 +77,9 @@ files:
 - ".rspec"
 - ".rubocop.yml"
 - ".travis.yml"
+- CHANGELOG.md
+- CODE_OF_CONDUCT.md
+- CONTRIBUTING.md
 - Gemfile
 - Gemfile.lock
 - LICENSE