sorbet-progress 0.1.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 07e527046e92f1f1e2495f003b8aa2609b9ff195661887a8c81c0c67d4345c5f
+  data.tar.gz: bbdb474efbac72727561ae902917ae921095b5db2a7968dd7a6a2c75e585418b
+SHA512:
+  metadata.gz: de774283bbc2b6554bc3a8444326697448a679ec27bae757c5b5069dd279fb9886f2e7d0191d6bd88aaaa9948f60849f776d9e81a1a0b9b819b4d071cc25303c
+  data.tar.gz: fc65da32aa0fff16fa567515a41883bea8a0ab0d146079acbae96d16edeb7364bd125d31b60e8727e14e73c76b183049493fa156d7ee958c1a62129c2b578073

data/.gitignore

@@ -0,0 +1,8 @@
+/.bundle/
+/.yardoc
+/_yardoc/
+/coverage/
+/doc/
+/pkg/
+/spec/reports/
+/tmp/

data/.rubocop.yml

@@ -0,0 +1,248 @@
+AllCops:
+  Exclude:
+    - 'bin/**/*'
+    - '.git/**/*'
+
+Layout/AlignArguments:
+  EnforcedStyle: with_fixed_indentation
+
+Layout/AlignParameters:
+  EnforcedStyle: with_fixed_indentation
+
+# Used consistently, both leading and trailing styles are valid, but
+# Singlebrook happens to use the trailing style.
+Layout/DotPosition:
+  EnforcedStyle: trailing
+
+Layout/EmptyLineAfterGuardClause:
+  Enabled: false
+
+# This cop has a bug in 0.52.0
+# https://github.com/bbatsov/rubocop/issues/5224
+Layout/EmptyLinesAroundArguments:
+  Enabled: false
+
+# Indent arrays so that the first element is relative to the first position of
+# the line where the opening bracket is.
+Layout/IndentFirstArrayElement:
+  EnforcedStyle: consistent
+
+# In a multiline method call, put the closing parenthesis on its own line.
+# The first argument may either be on the first line, or the second. Both of the
+# following are correct:
+#
+# ```
+# # A. correct
+# create(:user,
+#   client: foo,
+#   long_line: blah
+# )
+#
+# # B. also correct
+# create(
+#   :user,
+#   client: foo,
+#   long_line: blah
+# )
+#
+# # C. not preferred
+# user = create :user,
+#   client: foo,
+#   long_line: blah
+# ```
+#
+# Rubocop supports B, but not A. This project allows both, so this cop is
+# disabled.
+Layout/MultilineMethodCallBraceLayout:
+  Enabled: false
+
+Layout/MultilineMethodCallIndentation:
+  EnforcedStyle: indented
+
+Layout/MultilineOperationIndentation:
+  EnforcedStyle: indented
+
+# Sometimes splat is convenient, sometimes unnecessary. Too subtle to lint.
+Lint/UnneededSplatExpansion:
+  Enabled: false
+
+# Compared to metrics like `AbcSize` or `CyclomaticComplexity`, number of
+# lines is not a useful metric.
+Metrics/ClassLength:
+  Enabled: false
+
+# Compared to metrics like `AbcSize` or `CyclomaticComplexity`, number of
+# lines is not a useful metric.
+Metrics/BlockLength:
+  Enabled: false
+
+# Compared to metrics like `AbcSize` or `CyclomaticComplexity`, the number of
+# lines in a method is not a useful metric. It's common to have very long
+# methods (> 50 lines) which are quite simple. For example, a method that
+# returns a long string with only a few interpolations.
+Metrics/MethodLength:
+  Enabled: false
+
+# Compared to metrics like `AbcSize` or `CyclomaticComplexity`, the number of
+# lines in a module is not a useful metric.
+Metrics/ModuleLength:
+  Enabled: false
+
+# Too strict. Not all methods named `set_x` would make sense named `x=`.
+Naming/AccessorMethodName:
+  Enabled: false
+
+# It is a decades-old convention to use EOS as a heredoc delimiter. There is
+# not enough value in changinge this convention. SQL should still be used as
+# a delimiter when appropriate.
+Naming/HeredocDelimiterNaming:
+  Enabled: false
+
+# It is reasonable to use mathematical symbols in comments, or to relish what
+# little multilingualism we have in America by using native spellings, like
+# "façade" or "naïve".
+Style/AsciiComments:
+  Enabled: false
+
+# Giving the ivar a leading underscore implies that it should not be
+# set/referencd outside of the memoization method.
+Naming/MemoizedInstanceVariableName:
+  EnforcedStyleForLeadingUnderscores: required
+
+# Sometimes two chars, or even one, is acceptable.
+Naming/UncommunicativeMethodParamName:
+  Enabled: false
+
+# Use numbers wherever you like in your variables. Who cares.
+Naming/VariableNumber:
+  Enabled: false
+
+# Use the semantic style. If a block has side effects use `do`, and if it is
+# pure use `{}`. This style is too nuanced for a linter, so the cop is
+# disabled.
+Style/BlockDelimiters:
+  Enabled: false
+
+Style/BracesAroundHashParameters:
+  EnforcedStyle: context_dependent
+
+Style/ClassAndModuleChildren:
+  EnforcedStyle: nested
+
+Style/Documentation:
+  Exclude:
+    - 'test/**/*'
+
+# Use double negation wherever it would otherwise be impractical to convert
+# a value to an actual boolean.
+Style/DoubleNegation:
+  Enabled: false
+
+Style/EmptyElse:
+  EnforcedStyle: empty
+
+Style/EmptyMethod:
+  EnforcedStyle: expanded
+
+# Concerns:
+# 1. In 0.52.0, this complains about `strftime('%x')`. Annotating tokens in
+#    e.g. strftime would just be duplicating documenation.
+# 2. Annotating tokens in long format strings could make such lines very long.
+# 3. Annotation is not necessary in format strings with small numbers of tokens.
+Style/FormatStringToken:
+  Enabled: false
+
+# The decision of when to use a guard clause is too nuanced for a linter.
+Style/GuardClause:
+  Enabled: false
+
+# Avoid postfix (aka. modifier) conditional operator, except on the simplest
+# of lines. This is too nuanced for a linter.
+Style/IfUnlessModifier:
+  Enabled: false
+
+# When using a multiline proc in a hash (eg. `validates`), I don't want to use
+# lambda because then I'd have commas immediately after the "end", like `end,`.
+Style/Lambda:
+  Enabled: false
+
+# There is a known issue with `MixinGrouping` in rubocop 0.48.0
+# https://github.com/bbatsov/rubocop/issues/4172
+Style/MixinGrouping:
+  Enabled: false
+
+# Disabled, because we like to write tests like:
+#
+# expect(
+#   foo :bar, :baz
+# ).to # whatever
+#
+# When there's only one argument, and it's on its own line, there's no problem.
+Style/NestedParenthesizedCalls:
+  Enabled: false
+
+Style/Next:
+  MinBodyLength: 5 # The default of 3 is too low for my taste.
+
+# This is a new cop in rubocop 0.41, and I'm not sure if I want to adopt it yet.
+Style/NumericLiteralPrefix:
+  Enabled: false
+
+# Use `x > 0` because it is more specific than `x.positive?`.
+# However, `x.zero?` is acceptable because it is specific enough.
+Style/NumericPredicate:
+  Enabled: false
+
+# The decision of when to use slashes `/foo/` or percent-r `%r{foo}` is too
+# subtle to lint. Use whichever requires fewer backslash escapes.
+Style/RegexpLiteral:
+  Enabled: false
+
+# Disabled because it is overzealous in 0.50.0.
+# https://github.com/bbatsov/rubocop/issues/4731
+Style/SafeNavigation:
+  Enabled: false
+
+# The new recommendation to use `acc` and `elem` instead of `a` and `e` is fine,
+# if someone wants to change it. For now, it's fine to keep `a` and `e`.
+Style/SingleLineBlockParams:
+  Methods:
+    - reduce:
+        - a
+        - e
+    - inject:
+        - a
+        - e
+
+Style/TernaryParentheses:
+  EnforcedStyle: require_parentheses_when_complex
+
+# This cop has a bug in rubocop 0.62.0:
+# https://github.com/rubocop-hq/rubocop/issues/6627
+Style/TrailingCommaInArguments:
+  Enabled: false
+
+# Predicate methods, aka. question-mark methods, such as `def x?; @x; end` are
+# acceptable. See https://github.com/bbatsov/rubocop/issues/2736 for discussion.
+Style/TrivialAccessors:
+  AllowPredicates: true
+
+# Avoid postfix loops (e.g. `x until y`) except in utterly simple situations.
+# This is too nuanced for a linter.
+Style/WhileUntilModifier:
+  Enabled: false
+
+# We would like to use this cop, but it doesn't work in 0.49.
+Style/YodaCondition:
+  Enabled: false
+
+# Consider A and B below. A is more like normal English than B.
+#
+# ```
+# # A
+# qar_modules.length > 0 || question_assignments.length > 0
+# # B
+# !qar_modules.empty? || !question_assignments.empty?
+# ```
+Style/ZeroLengthPredicate:
+  Enabled: false

data/.travis.yml

@@ -0,0 +1,7 @@
+---
+sudo: false
+language: ruby
+cache: bundler
+rvm:
+  - 2.5.5
+before_install: gem install bundler -v 1.17.3

data/CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# 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, gender identity and expression, level of experience,
+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 jared@jaredbeck.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 [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

data/Gemfile

@@ -0,0 +1,8 @@
+# frozen_string_literal: true
+
+source 'https://rubygems.org'
+
+git_source(:github) { |repo_name| "https://github.com/#{repo_name}" }
+
+# Specify your gem's dependencies in sorbet-progress.gemspec
+gemspec

data/Gemfile.lock

@@ -0,0 +1,42 @@
+PATH
+  remote: .
+  specs:
+    sorbet-progress (0.1.0)
+      sorbet (>= 0.4.4365, <= 0.4.4366)
+      sorbet-runtime (>= 0.4.4365, <= 0.4.4366)
+
+GEM
+  remote: https://rubygems.org/
+  specs:
+    ast (2.4.0)
+    jaro_winkler (1.5.3)
+    minitest (5.11.3)
+    parallel (1.17.0)
+    parser (2.6.3.0)
+      ast (~> 2.4.0)
+    rainbow (3.0.0)
+    rubocop (0.72.0)
+      jaro_winkler (~> 1.5.1)
+      parallel (~> 1.10)
+      parser (>= 2.6)
+      rainbow (>= 2.2.2, < 4.0)
+      ruby-progressbar (~> 1.7)
+      unicode-display_width (>= 1.4.0, < 1.7)
+    ruby-progressbar (1.10.1)
+    sorbet (0.4.4366)
+      sorbet-static (= 0.4.4366)
+    sorbet-runtime (0.4.4366)
+    sorbet-static (0.4.4366-universal-darwin-14)
+    unicode-display_width (1.6.0)
+
+PLATFORMS
+  ruby
+
+DEPENDENCIES
+  bundler (~> 1.17)
+  minitest (~> 5.0)
+  rubocop (~> 0.72.0)
+  sorbet-progress!
+
+BUNDLED WITH
+   1.17.3

data/README.md

@@ -0,0 +1,31 @@
+# SorbetProgress
+
+Measure your progress as you adopt [sorbet](https://sorbet.org/). I find that 
+measuring progress keeps me motivated, which is crucial to finishing a project.
+
+## Installation
+
+Add this line to your application's Gemfile:
+
+```ruby
+gem 'sorbet-progress'
+```
+
+Then:
+
+    bundle
+
+Or install it yourself:
+
+    gem install sorbet-progress
+
+## Usage
+
+TBD
+
+## Contributing
+
+This project does not accept bug reports. Pull requests are welcome. 
+
+This project is intended to be a safe, welcoming space for collaboration, and
+contributors are expected to adhere to the [code of conduct](/CODE_OF_CONDUCT.md)

data/Rakefile

@@ -0,0 +1,12 @@
+# frozen_string_literal: true
+
+require 'bundler/gem_tasks'
+require 'rake/testtask'
+
+Rake::TestTask.new(:test) do |t|
+  t.libs << 'test'
+  t.libs << 'lib'
+  t.test_files = FileList['test/**/*_test.rb']
+end
+
+task default: :test