opal-rspec 0.8.0.alpha3 → 1.0.0.alpha1

data/rspec-mocks/upstream/BUILD_DETAIL.md

@@ -0,0 +1,149 @@
+<!---
+This file was generated on 2020-12-25T18:48:30+00:00 from the rspec-dev repo.
+DO NOT modify it by hand as your changes will get lost the next time it is generated.
+-->
+
+# The CI build, in detail
+
+The [Travis CI build](https://travis-ci.org/rspec/rspec-mocks)
+runs many verification steps to prevent regressions and
+ensure high-quality code. To run the Travis build locally, run:
+
+```
+$ script/run_build
+```
+
+It can be useful to run the build steps individually
+to repro a failing part of a Travis build. Let's break
+the build down into the individual steps.
+
+## Specs
+
+RSpec dogfoods itself. Its primary defense against regressions is its spec suite. Run with:
+
+```
+$ bundle exec rspec
+
+# or, if you installed your bundle with `--standalone --binstubs`:
+
+$ bin/rspec
+```
+
+The spec suite performs a couple extra checks that are worth noting:
+
+* *That all the code is warning-free.* Any individual example that produces output
+  to `stderr` will fail. We also have a spec that loads all the `lib` and `spec`
+  files in a newly spawned process to detect load-time warnings and fail if there
+  are any. RSpec must be warning-free so that users who enable Ruby warnings will
+  not get warnings from our code.
+* *That only a minimal set of stdlibs are loaded.* Since Ruby makes loaded libraries
+  available for use in any context, we want to minimize how many bits of the standard
+  library we load and use. Otherwise, RSpec's use of part of the standard library could
+  mask a problem where a gem author forgets to load a part of the standard library they
+  rely on. The spec suite contains a spec that defines a list of allowed loaded
+  stdlibs.
+
+In addition, we use [SimpleCov](https://github.com/colszowka/simplecov)
+to measure and enforce test coverage. If the coverage falls below a
+project-specific threshold, the build will fail.
+
+## Cukes
+
+RSpec uses [cucumber](https://cucumber.io/) for both acceptance testing
+and [documentation](https://relishapp.com/rspec). Since we publish our cukes
+as documentation, please limit new cucumber scenarios to user-facing examples
+that help demonstrate usage. Any tests that exist purely to prevent regressions
+should be written as specs, even if they are written in an acceptance style.
+Duplication between our YARD API docs and the cucumber documentation is fine.
+
+Run with:
+
+```
+$ bundle exec cucumber
+
+# or, if you installed your bundle with `--standalone --binstubs`:
+
+$ bin/cucumber
+```
+
+## YARD documentation
+
+RSpec uses [YARD](https://yardoc.org/) for API documentation on the [rspec.info site](https://rspec.info/).
+Our commitment to [SemVer](https://semver.org) requires that we explicitly
+declare our public API, and our build uses YARD to ensure that every
+class, module and method has either been labeled `@private` or has at
+least some level of documentation. For new APIs, this forces us to make
+an intentional decision about whether or not it should be part of
+RSpec's public API or not.
+
+To run the YARD documentation coverage check, run:
+
+```
+$ bundle exec yard stats --list-undoc
+
+# or, if you installed your bundle with `--standalone --binstubs`:
+
+$ bin/yard stats --list-undoc
+```
+
+We also want to prevent YARD errors or warnings when actually generating
+the docs. To check for those, run:
+
+```
+$ bundle exec yard doc --no-cache
+
+# or, if you installed your bundle with `--standalone --binstubs`:
+
+$ bin/yard doc --no-cache
+```
+
+## RuboCop
+
+We use [RuboCop](https://github.com/rubocop-hq/rubocop) to enforce style
+conventions on the project so that the code has stylistic consistency
+throughout. Run with:
+
+```
+$ bundle exec rubocop lib
+
+# or, if you installed your bundle with `--standalone --binstubs`:
+
+$ bin/rubocop lib
+```
+
+Our RuboCop configuration is a work-in-progress, so if you get a failure
+due to a RuboCop default, feel free to ask about changing the
+configuration. Otherwise, you'll need to address the RuboCop failure,
+or, as a measure of last resort, by wrapping the offending code in
+comments like `# rubocop:disable SomeCheck` and `# rubocop:enable SomeCheck`.
+
+## Run spec files one-by-one
+
+A fast TDD cycle depends upon being able to run a single spec file,
+without the rest of the test suite. While rare, it's fairly easy to
+create a situation where a spec passes when the entire suite runs
+but fails when its individual file is run. To guard against this,
+our CI build runs each spec file individually, using a bit of bash like:
+
+```
+for file in `find spec -iname '*_spec.rb'`; do
+  echo "Running $file"
+  bin/rspec $file -b --format progress
+done
+```
+
+Since this step boots RSpec so many times, it runs much, much
+faster when we can avoid the overhead of bundler. This is a main reason our
+CI build installs the bundle with `--standalone --binstubs` and
+runs RSpec via `bin/rspec` rather than `bundle exec rspec`.
+
+## Running the spec suite for each of the other repos
+
+While each of the RSpec repos is an independent gem (generally designed
+to be usable on its own), there are interdependencies between the gems,
+and the specs for each tend to use features from the other gems. We
+don't want to merge a pull request for one repo that might break the
+build for another repo, so our CI build includes a spec that runs the
+spec suite of each of the _other_ project repos. Note that we only run
+the spec suite, not the full build, of the other projects, as the spec
+suite runs very quickly compared to the full build.

data/rspec-mocks/upstream/CODE_OF_CONDUCT.md

@@ -0,0 +1,59 @@
+<!---
+This file was generated on 2020-12-25T18:48:30+00:00 from the rspec-dev repo.
+DO NOT modify it by hand as your changes will get lost the next time it is generated.
+-->
+
+# Contributor Code of Conduct
+
+For the purpose of building a welcoming, harassment-free community that
+values contributions from anyone, the RSpec project has adopted the
+following code of conduct. All contributors and participants (including
+maintainers!) are expected to abide by its terms.
+
+As contributors and maintainers of this project, and in the interest of
+fostering an open and welcoming community, we pledge to respect all people who
+contribute through reporting issues, posting feature requests, updating
+documentation, submitting pull requests or patches, and other activities.
+
+We are committed to making participation in this project a harassment-free
+experience for everyone, regardless of level of experience, gender, gender
+identity and expression, sexual orientation, disability, personal appearance,
+body size, race, ethnicity, age, religion, or nationality.
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery
+* Personal attacks
+* Trolling or insulting/derogatory comments
+* Public or private harassment
+* Publishing other's private information, such as physical or electronic
+  addresses, without explicit permission
+* Other unethical or unprofessional conduct
+
+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.
+
+By adopting this Code of Conduct, project maintainers commit themselves to
+fairly and consistently applying these principles to every aspect of managing
+this project. Project maintainers who do not follow or enforce the Code of
+Conduct may be permanently removed from the project team.
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community.
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting one of the project maintainers listed at
+https://rspec.info/about/. All complaints will be reviewed and investigated
+and will result in a response that is deemed necessary and appropriate to the
+circumstances. Maintainers are obligated to maintain confidentiality with
+regard to the reporter of an incident.
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.3.0, available at
+[https://contributor-covenant.org/version/1/3/0/][version]
+
+[homepage]: https://contributor-covenant.org
+[version]: https://contributor-covenant.org/version/1/3/0/

data/rspec-mocks/upstream/CONTRIBUTING.md

@@ -0,0 +1,86 @@
+<!---
+This file was generated on 2020-12-25T18:48:30+00:00 from the rspec-dev repo.
+DO NOT modify it by hand as your changes will get lost the next time it is generated.
+-->
+
+# Contributing
+
+RSpec is a community-driven project that has benefited from improvements from over *500* contributors.
+We welcome contributions from *everyone*. While contributing, please follow the project [code of conduct](CODE_OF_CONDUCT.md), so that everyone can be included.
+
+If you'd like to help make RSpec better, here are some ways you can contribute:
+
+  - by running RSpec HEAD to help us catch bugs before new releases
+  - by [reporting bugs you encounter](https://github.com/rspec/rspec-mocks/issues/new) with [report template](#report-template)
+  - by [suggesting new features](https://github.com/rspec/rspec-mocks/issues/new)
+  - by improving RSpec's [Relish](https://relishapp.com/rspec) or [API](https://rspec.info/documentation/) documentation
+  - by improving [RSpec's website](https://rspec.info/) ([source](https://github.com/rspec/rspec.github.io))
+  - by taking part in [feature and issue discussions](https://github.com/rspec/rspec-mocks/issues)
+  - by adding a failing test for reproducible [reported bugs](https://github.com/rspec/rspec-mocks/issues)
+  - by reviewing [pull requests](https://github.com/rspec/rspec-mocks/pulls) and suggesting improvements
+  - by [writing code](DEVELOPMENT.md) (no patch is too small! fix typos or bad whitespace)
+
+If you need help getting started, check out the [DEVELOPMENT](DEVELOPMENT.md) file for steps that will get you up and running.
+
+Thanks for helping us make RSpec better!
+
+## `Small` issues
+
+These issue are ones that we be believe are best suited for new contributors to
+get started with. They represent a meaningful contribution to the project that
+should not be too hard to pull off.
+
+## Report template
+
+Having a way to reproduce your issue will be very helpful for others to help confirm,
+investigate and ultimately fix your issue. You can do this by providing an executable
+test case. To make this process easier, we have prepared one basic
+[bug report templates](REPORT_TEMPLATE.md) for you to use as a starting point.
+
+## Maintenance branches
+
+Maintenance branches are how we manage the different supported point releases
+of RSpec. As such, while they might look like good candidates to merge into
+main, please do not open pull requests to merge them.
+
+## Working on multiple RSpec gems at the same time
+
+RSpec is composed of multiple gems (`rspec-core`, `rspec-mocks`, etc). Sometimes you have
+to work on a combination of them at the same time. When submitting your code for review,
+we ask that you get a passing build (green CI). If you are working across the repositories,
+please add a commit that temporarily pins your PR to the right branch of the other repository
+you depend on. For example, if we wanted a change in `rspec-expectations` that relied on a
+change for on `rspec-mocks`. We add a commit with the title:
+
+>[WIP] Use rspec-mocks with "custom-failure-message" branch
+
+And content:
+
+```diff
+diff --git a/Gemfile b/Gemfile
+
+-%w[rspec rspec-core rspec-mocks rspec-support].each do |lib|
++%w[rspec rspec-core rspec-support].each do |lib|
+   library_path = File.expand_path("../../#{lib}", __FILE__)
+   if File.exist?(library_path) && !ENV['USE_GIT_REPOS']
+     gem lib, :path => library_path
+@@ -11,6 +11,7 @@ branch = File.read(File.expand_path("../maintenance-branch", __FILE__)).chomp
+     gem lib, :git => "https://github.com/rspec/#{lib}.git", :branch => branch
+   end
+ end
++gem 'rspec-mocks', :git => "https://github.com/rspec/rspec-mocks.git", :branch => "custom-failure-message"
+```
+
+In general the process is:
+1. Create PRs explaining what you are trying to achieve.
+2. Pin the repositories to each other.
+3. Check they pass (go green).
+4. Await review if appropriate.
+5. Remove the commit from step 2. We will merge ignoring the failure.
+6. Remove the commit from the other, check it passes with the other commit now on `main`.
+7. Merge the other.
+8. We will trigger builds for the `main` branch of affected repositories to check if everything is in order.
+
+Steps 5-8 should happen continuously (e.g. one after another but within a short timespan)
+so that we don't leave a broken main around. It is important to triage that build process
+and revert if necessary.