Merge pull request #162 from codfish/deps

Deps

.github/workflows/validate.yml

@@ -8,7 +8,7 @@ jobs:
 
     strategy:
       matrix:
-        node: [10.x, 11.x, 12.x]
+        node: [10.x, 11.x, 12.x, 14.x]
 
     steps:
       - uses: actions/checkout@v1
@@ -22,13 +22,6 @@ jobs:
         env:
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
 
-      - name: lint commits
-        run:
-          npx commitlint --config="./src/config/commitlint.config.js" --from="origin/${{
-          github.base_ref }}" --to="origin/${{ github.head_ref }}"
-        env:
-          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
-
       - run: npm run build
         env:
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

.gitignore

@@ -1,10 +1,7 @@
 node_modules
 coverage
 dist
-.opt-in
-.opt-out
 .DS_Store
-.eslintcache
 
 # these cause more harm than good
 # when working with contributors

.huskyrc.js

@@ -0,0 +1 @@
+module.exports = require('./src/config/huskyrc')

.prettierrc.js

@@ -1 +1,7 @@
-module.exports = require('./src/config/prettierrc')
+const prettierConfig = require('./src/config/prettierrc')
+
+module.exports = Object.assign({}, prettierConfig, {
+  // to prevent additional conflicts with update kcd-scripts, making
+  // backmerging a little easier.
+  printWidth: 80,
+})

CHANGELOG.md

@@ -1,5 +1,5 @@
 # CHANGELOG
 
 The changelog is automatically updated using
-[semantic-release](https://github.com/semantic-release/semantic-release). You can see it on the
-[releases page](../../releases).
+[semantic-release](https://github.com/semantic-release/semantic-release). You
+can see it on the [releases page](../../releases).

CONTRIBUTING.md

@@ -2,70 +2,48 @@
 
 Thanks for being willing to contribute!
 
-**Working on your first Pull Request?** You can learn how from this _free_ series [How to Contribute
-to an Open Source Project on GitHub][egghead]
+**Working on your first Pull Request?** You can learn how from this _free_
+series [How to Contribute to an Open Source Project on GitHub][egghead]
 
 ## Project setup
 
-1.  Fork and clone the repo
-2.  `$ npm install` to install dependencies
-3.  `$ npm run validate` to validate you've got it working
-4.  Create a branch for your PR
+1. Fork and clone the repo
+2. `$ npm install` to install dependencies
+3. `$ npm run validate` to validate you've got it working
+4. Create a branch for your PR
 
-> Tip: Keep your `master` branch pointing at the original repository and make pull requests from
-> branches on your fork. To do this, run:
+> Tip: Keep your `master` branch pointing at the original repository and make
+> pull requests from branches on your fork. To do this, run:
 >
 > ```
 > git remote add upstream https://github.com/codfish/cod-scripts.git
 > git fetch upstream
 > git branch --set-upstream-to=upstream/master master
 > ```
 >
-> This will add the original repository as a "remote" called "upstream," Then fetch the git
-> information from that remote, then set your local `master` branch to use the upstream master
-> branch whenever you run `git pull`. Then you can make all of your pull request branches based on
-> this `master` branch. Whenever you want to update your version of `master`, do a regular
-> `git pull`.
+> This will add the original repository as a "remote" called "upstream," Then
+> fetch the git information from that remote, then set your local `master`
+> branch to use the upstream master branch whenever you run `git pull`. Then you
+> can make all of your pull request branches based on this `master` branch.
+> Whenever you want to update your version of `master`, do a regular `git pull`.
 
 ## Committing and Pushing changes
 
-This project uses [`semantic-release`][semantic-release] to do automatic releases and generate a
-changelog based on the commit history. So we follow [a convention][convention] for commit messages.
-You don't have to follow this convention if you don't want to. Just know that when we merge your
-commit, we'll probably use "Squash and Merge" so we can change the commit message :)
-
-Please make sure to run the tests before you commit your changes. You can run `npm run test:update`
-which will update any snapshots that need updating. Make sure to include those changes (if they
-exist) in your commit.
-
-### opt in/out of git hooks
-
-There are git hooks set up with this project that are automatically installed when you install
-dependencies. They're really handy, but are turned off by default (so as to not hinder new
-contributors). You can opt into these by creating a file called `.opt-in` at the root of the project
-and putting this inside:
-
-```
-pre-commit
-```
-
-One of the things that the git hooks does is automatically format the files you change. It does this
-by reformating the entire file and running `git add` on the file after. This breaks workflows where
-you're trying to commit portions of the file only. You can always run your commit with
-`--no-verify`, but if this is a bummer to your workflow, you can add an `.opt-out` file with the
-contents:
-
-```
-autoformat
-```
+Please make sure to run the tests before you commit your changes. You can run
+`npm run test:update` which will update any snapshots that need updating. Make
+sure to include those changes (if they exist) in your commit.
 
 ## Help needed
 
 Please checkout the [the open issues][issues]
 
-Also, please watch the repo and respond to questions/bug reports/feature requests! Thanks!
+Also, please watch the repo and respond to questions/bug reports/feature
+requests! Thanks!
+
+<!-- prettier-ignore-start -->
 
-[egghead]: https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github
+[egghead]:
+  https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github
 [semantic-release]: https://npmjs.com/package/semantic-release
 [convention]:
   https://github.com/conventional-changelog/conventional-changelog-angular/blob/ed32559941719a130bb0327f886d6a32a8cbc2ba/convention.md

README.md

@@ -4,17 +4,23 @@
 <p>CLI toolbox for common scripts for my projects</p>
 </div>
 
-<hr />
-
-[![version][version-badge]][package] [![downloads][downloads-badge]][npmcharts]
-[![GitHub Workflow Status][actions-badge]][actions-badge] [![MIT License][license-badge]][license]
-[![PRs Welcome][prs-badge]][prs] [![Semantic Release][semantic-release-badge]][semantic-release]
+---
+
+<!-- prettier-ignore-start -->
+[![version][version-badge]][package]
+[![downloads][downloads-badge]][npmcharts]
+[![GitHub Workflow Status][actions-badge]][actions-badge]
+[![MIT License][license-badge]][license]
+[![PRs Welcome][prs-badge]][prs]
+[![Semantic Release][semantic-release-badge]][semantic-release]
 [![Commitizen friendly][commitizen-badge]][commitizen]
+<!-- prettier-ignore-end -->
 
 ## Motivation
 
-This helps me maintain personal & work projects without duplication. This is a CLI that abstracts
-away all configuration for my open source projects for linting, testing, building, and more.
+This helps me maintain personal & work projects without duplication. This is a
+CLI that abstracts away all configuration for my open source projects for
+linting, testing, building, and more.
 
 ## Table of Contents
 
@@ -24,16 +30,15 @@ away all configuration for my open source projects for linting, testing, buildin
 - [Installation](#installation)
 - [Usage](#usage)
   - [Overriding Config](#overriding-config)
-  - [Flow support](#flow-support)
-- [Inspiration](#inspiration)
+  - [TypeScript Support](#typescript-support)
 - [LICENSE](#license)
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
 ## Installation
 
-This module is distributed via [npm][npm] which is bundled with [node][node] and should be installed
-as one of your project's `devDependencies`:
+This module is distributed via [npm][npm] which is bundled with [node][node] and
+should be installed as one of your project's `devDependencies`:
 
 ```sh
 npm install --save-dev cod-scripts
@@ -42,26 +47,29 @@ npm install --save @babel/runtime
 
 ## Usage
 
-This is a CLI and exposes a bin called `cod-scripts`. I don't really plan on documenting or testing
-it super duper well because it's really specific to my needs. You'll find all available scripts in
-`src/scripts`.
+This is a CLI and exposes a bin called `cod-scripts`. I don't really plan on
+documenting or testing it super duper well because it's really specific to my
+needs. You'll find all available scripts in `src/scripts`.
 
-This project actually dogfoods itself. If you look in the `package.json`, you'll find scripts with
-`node src {scriptName}`. This serves as an example of some of the things you can do with
-`cod-scripts`.
+This project actually dogfoods itself. If you look in the `package.json`, you'll
+find scripts with `node src {scriptName}`. This serves as an example of some of
+the things you can do with `cod-scripts`.
 
 ### Overriding Config
 
-Unlike `react-scripts`, `cod-scripts` allows you to specify your own configuration for things and
-have that plug directly into the way things work with `cod-scripts`. There are various ways that it
-works, but basically if you want to have your own config for something, just add the configuration
-and `cod-scripts` will use that instead of it's own internal config. In addition, `cod-scripts`
-exposes its configuration so you can use it and override only the parts of the config you need to.
+Unlike `react-scripts`, `cod-scripts` allows you to specify your own
+configuration for things and have that plug directly into the way things work
+with `cod-scripts`. There are various ways that it works, but basically if you
+want to have your own config for something, just add the configuration and
+`cod-scripts` will use that instead of it's own internal config. In addition,
+`cod-scripts` exposes its configuration so you can use it and override only the
+parts of the config you need to.
 
-This can be a very helpful way to make editor integration work for tools like ESLint which require
-project-based ESLint configuration to be present to work.
+This can be a very helpful way to make editor integration work for tools like
+ESLint which require project-based ESLint configuration to be present to work.
 
-So, if we were to do this for ESLint, you could create an `.eslintrc` with the contents of:
+So, if we were to do this for ESLint, you could create an `.eslintrc` with the
+contents of:
 
 ```
 {"extends": "./node_modules/cod-scripts/eslint.js"}
@@ -91,7 +99,8 @@ module.exports = Object.assign(jestConfig, {
 });
 ```
 
-Or, for `commitlint`, a `commitlint.config.js` file or `commitlint` prop in package.json:
+Or, for `commitlint`, a `commitlint.config.js` file or `commitlint` prop in
+package.json:
 
 ```js
 // commitlint.config.js or .commitlintrc.js
@@ -118,30 +127,37 @@ module.exports = {
 }
 ```
 
-> Note: `cod-scripts` intentionally does not merge things for you when you start configuring things
-> to make it less magical and more straightforward. Extending can take place on your terms. I think
-> this is actually a great way to do this.
+> Note: `cod-scripts` intentionally does not merge things for you when you start
+> configuring things to make it less magical and more straightforward. Extending
+> can take place on your terms. I think this is actually a great way to do this.
+
+### TypeScript Support
 
-### Flow support
+If the `tsconfig.json`-file is present in the project root directory and
+`typescript` is a dependency the `@babel/preset-typescript` will automatically
+get loaded when you use the default babel config that comes with `cod-scripts`.
+If you customised your `.babelrc`-file you might need to manually add
+`@babel/preset-typescript` to the `presets`-section.
 
-If the `flow-bin` is a dependency on the project the `@babel/preset-flow` will automatically get
-loaded when you use the default babel config that comes with `cod-scripts`. If you customised your
-`.babelrc`-file you might need to manually add `@babel/preset-flow` to the `presets`-section.
+`cod-scripts` will automatically load any `.ts` and `.tsx` files, including the
+default entry point, so you don't have to worry about any rollup configuration.
 
-## Inspiration
+If you have a `typecheck` script (normally set to `kcd-scripts typecheck`) that
+will be run as part of the `validate` script (which is run as part of the
+`pre-commit` script as well).
 
-This was forked from `kentcdodds/kcd-scripts`. This is
-[inspired by `react-scripts`](https://github.com/kentcdodds/kcd-scripts#inspiration).
+TypeScript definition files will also automatically be generated during the
+`build` script.
 
 ## LICENSE
 
 MIT
 
-[npm]: https://www.npmjs.com/
+<!-- prettier-ignore-start -->
+[npm]: https://www.npmjs.com
 [node]: https://nodejs.org
 [semantic-release]: https://github.com/semantic-release/semantic-release
-[semantic-release-badge]:
-  https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg
+[semantic-release-badge]: https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg
 [prs]: http://makeapullrequest.com
 [prs-badge]: https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square
 [commitizen]: http://commitizen.github.io/cz-cli/
@@ -154,3 +170,4 @@ MIT
 [license]: https://github.com/codfish/cod-scripts/blob/master/LICENSE
 [actions]: https://github.com/codfish/cod-scripts/actions
 [actions-badge]: https://img.shields.io/github/workflow/status/codfish/cod-scripts/Release/master
+<!-- prettier-ignore-end -->

husky.js

@@ -0,0 +1 @@
+module.exports = require('./dist/config/huskyrc');

other/MAINTAINING.md

@@ -0,0 +1,84 @@
+# Maintaining
+
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+
+**Table of Contents**
+
+- [Code of Conduct](#code-of-conduct)
+- [Issues](#issues)
+- [Pull Requests](#pull-requests)
+- [Release](#release)
+- [Thanks!](#thanks)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+This is documentation for maintainers of this project.
+
+## Code of Conduct
+
+Please review, understand, and be an example of it. Violations of the code of
+conduct are taken seriously, even (especially) for maintainers.
+
+## Issues
+
+We want to support and build the community. We do that best by helping people
+learn to solve their own problems. We have an issue template and hopefully most
+folks follow it. If it's not clear what the issue is, invite them to create a
+minimal reproduction of what they're trying to accomplish or the bug they think
+they've found.
+
+Once it's determined that a code change is necessary, point people to
+[makeapullrequest.com](http://makeapullrequest.com) and invite them to make a
+pull request. If they're the one who needs the feature, they're the one who can
+build it. If they need some hand holding and you have time to lend a hand,
+please do so. It's an investment into another human being, and an investment
+into a potential maintainer.
+
+Remember that this is open source, so the code is not yours, it's ours. If
+someone needs a change in the codebase, you don't have to make it happen
+yourself. Commit as much time to the project as you want/need to. Nobody can ask
+any more of you than that.
+
+## Pull Requests
+
+As a maintainer, you're fine to make your branches on the main repo or on your
+own fork. Either way is fine.
+
+When we receive a pull request, a GitHub Action is kicked off automatically (see
+the `.github/workflows/validate.yml` for what runs in the Action). We avoid
+merging anything that breaks the GitHub Action.
+
+Please review PRs and focus on the code rather than the individual. You never
+know when this is someone's first ever PR and we want their experience to be as
+positive as possible, so be uplifting and constructive.
+
+When you merge the pull request, 99% of the time you should use the
+[Squash and merge](https://help.github.com/articles/merging-a-pull-request/)
+feature. This keeps our git history clean, but more importantly, this allows us
+to make any necessary changes to the commit message so we release what we want
+to release. See the next section on Releases for more about that.
+
+## Release
+
+Our releases are automatic. They happen whenever code lands into `master`. A
+GitHub Action gets kicked off and if it's successful, a tool called
+[`semantic-release`](https://github.com/semantic-release/semantic-release) is
+used to automatically publish a new release to npm as well as a changelog to
+GitHub. It is only able to determine the version and whether a release is
+necessary by the git commit messages. With this in mind, **please brush up on
+[the commit message convention][commit] which drives our releases.**
+
+> One important note about this: Please make sure that commit messages do NOT
+> contain the words "BREAKING CHANGE" in them unless we want to push a major
+> version. I've been burned by this more than once where someone will include
+> "BREAKING CHANGE: None" and it will end up releasing a new major version. Not
+> a huge deal honestly, but kind of annoying...
+
+## Thanks!
+
+Thank you so much for helping to maintain this project!
+
+<!-- prettier-ignore-start -->
+[commit]: https://github.com/conventional-changelog-archived-repos/conventional-changelog-angular/blob/ed32559941719a130bb0327f886d6a32a8cbc2ba/convention.md
+<!-- prettier-ignore-end -->