fix(dist): import module

[gregswindle]

Pull Request (PR)

Update outdated rollup-plugins.

The dev-dependency rollup-plugin-node-resolve
introduced a breaking change. Once the mainFields
property had values, rollup.js worked again.

Also set package.json#files to "dist", which
ensures the distribution if much smaller, e.g.,

> npm pack

npm notice 
npm notice 📦  archetypes-rules@1.1.0
npm notice === Tarball Contents === 
npm notice 10.4kB package.json            
npm notice 5.6kB  CHANGELOG.md            
npm notice 1.1kB  LICENSE                 
npm notice 28.5kB README.md               
npm notice 21.7kB dist/archetypes-rules.js
npm notice === Tarball Details === 
npm notice name:          archetypes-rules                        
npm notice version:       1.1.0                                   
npm notice filename:      archetypes-rules-1.1.0.tgz              
npm notice package size:  15.9 kB                                 
npm notice unpacked size: 67.4 kB                                 
npm notice shasum:        3bfa34ba536ae0da9ad269be437b816666c8db33
npm notice integrity:     sha512-uBVSNTpQopypQ[...]AEgNGpHoZIBUQ==
npm notice total files:   5                                       
npm notice 
archetypes-rules-1.1.0.tgz

Introduce two new npm-scripts to make pre-release
testing easier:

1. bundle:clean - removes ./dist/ and *.tgz
2. postbundle - calls npm pack

Associated issue(s)

Closes #35
Closes #36
Closes #37
Closes #38
Closes #39

---

• 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
Duplications
Maintainability
Reliability
Security
Test coverage

Code quality, vulnerability, and standards compliance tools

Code Style	Linters	Test frameworks
Standard JS user guide	ESlint user guide	Jest user guide

How to format, lint, and test your changes

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

$ npm test

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

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.

---

[qlty-cloud-legacy]

Code Climate has analyzed commit 01dd9dc and detected 2 issues on this pull request.

Here's the issue category breakdown:

Category	Count
Duplication	2

View more on Code Climate.