Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: evaluate RuleElements with @sindresorhus/ow#isValid #101

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

gregswindle
Copy link
Contributor

@gregswindle gregswindle commented Aug 27, 2019

git Pull Request Pull Request (PR)

  1. Refactor all RuleElement operator methods to use @sindresorhus/ow#isValid.
  2. Remove unused development and production dependencies.
  3. Update all third-party dependencies to their latest versions.
  4. Rename archetypes-rules => @archetypes/rules.

Associated issue(s)

Closes #97
Closes #103


  • 1. The acceptance criteria for all associated issues have been
    completed, tested, and validated.
  • 2. The README either reflects my changes or does not require updates.
  • 3. The CONTRIBUTING document either reflects my changes or does not
    require updates.

View the "Code Review Cheat-sheet"...

Rule 1: Review all Code before Releasing it

Do the code reviews before deployment.

Why:

Your team will end up, on average, spending 7% more of its time on building
new features compared with those who do after, and 10% more than those who
don’t do code reviews at all.

Rule 2: All developers review code

Make sure all your developers get to review code.

Why:

This will improve the feeling of empowerment, facilitate knowledge transfer,
and improve developer satisfaction and productivity.

Rule 3: Four-to-Eight (4-8) Hours per Developers per Week

The optimal amount of time to spend on code reviews is between 0.5 to 1 day per
week per developer.

Rule 4: Don't Release Code that Fails Reviews

Make code reviews blocking, that is, don’t deploy before they have been carried
out.

Rule 5: More Rigor, Better Quality and Velocity

Be strict and thorough when reviewing code.

Why:

Your code quality and velocity will thank you.


Code quality summary

Measure Scores
Quality gate Sonar Alert Status Metrics
Duplications Sonar Duplicated Lines Density Metrics
Maintainability Sonar Code Smells Metrics
Sonar Sqale Rating Metrics
Sonar Sqale Index Metrics
Sonar Ncloc Metrics
Reliability Sonar Reliability Rating Metrics
Sonar Bugs Metrics
Security Sonar Security Rating Metrics
Sonar Vulnerabilities Metrics
Test coverage Sonar Coverage Metrics

Code quality, vulnerability, and standards compliance tools

Code Style Linters Test frameworks
JavaScript Style Guide ESLint Jest BDD
Standard JS user guide link-external ESlint user guide link-external Jest user guide link-external

How to format, lint, and test your changes

Open a Terminal, go to the root directory for archetypes-rules, and run:

$ npm test

info Completed tasks are not required to open a PR, and may
be addressed while the PR is open.

alert All tasks must be completed and verified
before a PR may be merged into master, however.

How to test a release

The Pre-release test instructions include step-by-step guidelines for bundling, packing, and testing this module as it would be released on NPM.


Update dev-dependencies:

1.  [email protected] --save-dev
2.  [email protected] --save-dev
3.  [email protected] --save-dev

Remove unused dev and prod dependencies.

\#97
@gregswindle gregswindle self-assigned this Aug 27, 2019
@gregswindle gregswindle added type: breaking change Modifications affect or replace the public API. ⇧ Bumps the MAJOR semver. type: dependency Update or pin a third-party library. ⇧ Bump the PATCH semver. type: refactor Restructuring source code without changing its external behavior. type: test Adding, correcting, or improving tests (coverage). labels Aug 27, 2019
Copy link

@codeclimate codeclimate bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR diff size of 41721 lines exceeds the maximum allowed for the inline comments feature.

Copy link

@codeclimate codeclimate bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR diff size of 43253 lines exceeds the maximum allowed for the inline comments feature.

@commonality commonality deleted a comment Sep 7, 2019
Replace module lodash.hasin (4 KB) with private
function objectHasPropertyName (500 B)

#97
- Remove ArrayVariable.prototype.isNonEmpty
- Rename Proposition results' names to match their
  operator method names.

#103
Move up function assignTypeTo for reuse.

#97
Copy link

@codeclimate codeclimate bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR diff size of 43356 lines exceeds the maximum allowed for the inline comments feature.

@codeclimate
Copy link

codeclimate bot commented Sep 7, 2019

Code Climate has analyzed commit b8629f2 and detected 0 issues on this pull request.

View more on Code Climate.

@commonality commonality deleted a comment Sep 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: breaking change Modifications affect or replace the public API. ⇧ Bumps the MAJOR semver. type: dependency Update or pin a third-party library. ⇧ Bump the PATCH semver. type: refactor Restructuring source code without changing its external behavior. type: test Adding, correcting, or improving tests (coverage).
Projects
None yet
1 participant