├── .babelrc
├── .editorconfig
├── .eslintrc.json
├── .github
├── CONTRIBUTING.md
├── ISSUE_TEMPLATE.md
└── PULL_REQUEST_TEMPLATE.md
├── .gitignore
├── .prettierignore
├── .prettierrc.yml
├── .travis.yml
├── CHANGELOG.md
├── LICENSE
├── README.md
├── client
├── app.js
├── components
│ ├── auth-form.js
│ ├── index.js
│ ├── navbar.js
│ ├── user-home.js
│ └── user-home.spec.js
├── history.js
├── index.js
├── routes.js
├── socket.js
└── store
│ ├── index.js
│ ├── user.js
│ └── user.spec.js
├── package-lock.json
├── package.json
├── public
├── favicon.ico
├── index.html
└── style.css
├── script
├── deploy
├── encrypt-heroku-auth-token.js
├── keyComments.json
├── seed.js
└── seed.spec.js
├── server
├── api
│ ├── index.js
│ ├── users.js
│ └── users.spec.js
├── auth
│ ├── google.js
│ └── index.js
├── db
│ ├── db.js
│ ├── index.js
│ └── models
│ │ ├── index.js
│ │ ├── user.js
│ │ └── user.spec.js
├── index.js
└── socket
│ └── index.js
└── webpack.config.js
/.babelrc:
--------------------------------------------------------------------------------
1 | {
2 | "presets": [
3 | "@babel/react",
4 | "@babel/env"
5 | /*
6 | Babel uses these "presets" to know how to transpile your Javascript code. Here's what we're saying with these:
7 |
8 | 'react': teaches Babel to recognize JSX - a must have for React!
9 |
10 | 'env': teaches Babel to transpile Javascript . This preset is highly configurable, and you can reduce the size of your bundle by limiting the number of features you transpile. Learn more here: https://github.com/babel/babel-preset-env
11 | */
12 | ],
13 | "plugins": [
14 | /*
15 | These plugins teach Babel to recognize EcmaScript language features that have reached "stage 2" in the process of approval for inclusion in the official EcmaScript specification (called the "TC39 process"). There are 5 stages in the process, starting at 0 (basically a brand new proposal) going up to 4 (finished and ready for inclusion). Read more about it here: http://2ality.com/2015/11/tc39-process.html. Using new language features before they're officially part of EcmaScript is fun, but it also carries a risk: sometimes proposed features can change substantially (or be rejected entirely) before finally being included in the language, so if you jump on the bandwagon too early, you risk having your code be dependent on defunct/nonstandard syntax! "Stage 2" is a fairly safe place to start - after stage 2, the feature is well on its way to official inclusion and only minor changes are expected.
16 | */
17 | "@babel/plugin-syntax-dynamic-import",
18 | "@babel/plugin-syntax-import-meta",
19 | "@babel/plugin-proposal-class-properties",
20 | "@babel/plugin-proposal-json-strings",
21 | [
22 | "@babel/plugin-proposal-decorators",
23 | {
24 | "legacy": true
25 | }
26 | ],
27 | "@babel/plugin-proposal-function-sent",
28 | "@babel/plugin-proposal-export-namespace-from",
29 | "@babel/plugin-proposal-numeric-separator",
30 | "@babel/plugin-proposal-throw-expressions"
31 | ]
32 | }
33 |
--------------------------------------------------------------------------------
/.editorconfig:
--------------------------------------------------------------------------------
1 | # editorconfig.org
2 | root = true
3 |
4 | [*]
5 | indent_style = space
6 | indent_size = 2
7 | end_of_line = lf
8 | charset = utf-8
9 | trim_trailing_whitespace = true
10 | insert_final_newline = true
11 |
12 | [*.md]
13 | trim_trailing_whitespace = false
14 |
15 | [*.{yml,yaml}]
16 | indent_style = space
17 |
--------------------------------------------------------------------------------
/.eslintrc.json:
--------------------------------------------------------------------------------
1 | {
2 | "root": true,
3 | "extends": ["fullstack", "prettier", "prettier/react"],
4 | "rules": {
5 | "semi": 0
6 | }
7 | }
8 |
--------------------------------------------------------------------------------
/.github/CONTRIBUTING.md:
--------------------------------------------------------------------------------
1 | # Contributing to this Project
2 |
3 | For pull requests to be merged, authors should:
4 |
5 | * Write any applicable unit tests
6 | * Add any relevant documentation
7 | * Reference any relevant issues
8 | * Obtain a review from a team member
9 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE.md:
--------------------------------------------------------------------------------
1 | For bugs, please include the following:
2 |
3 | * What is the expected behavior?
4 | * What is the actual behavior?
5 | * What steps reproduce the behavior?
6 |
7 | For features, please specify at least minimal requirements, e.g.:
8 |
9 | * "As a user, I want a notification badge showing unread count, so I can easily manage my messages"
10 | * "As a developer, I want linting to work properly with JSX, so I can see when there is a mistake"
11 | * "As an admin, I want a management panel for users, so I can delete spurious accounts"
12 |
13 | ---
14 |
15 | _Issue description here…_
16 |
--------------------------------------------------------------------------------
/.github/PULL_REQUEST_TEMPLATE.md:
--------------------------------------------------------------------------------
1 | ### Assignee Tasks
2 |
3 | * [ ] added unit tests (or none needed)
4 | * [ ] written relevant docs (or none needed)
5 | * [ ] referenced any relevant issues (or none exist)
6 |
7 | ### Guidelines
8 |
9 | Please add a description of this Pull Request's motivation, scope, outstanding issues or potential alternatives, reasoning behind the current solution, and any other relevant information for posterity.
10 |
11 | ---
12 |
13 | _Your PR Notes Here_
14 |
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | node_modules
2 | public/bundle.js
3 | public/bundle.js.map
4 | secrets.js
5 | .DS_Store
6 | npm-debug.log
7 | yarn-error.log
8 |
--------------------------------------------------------------------------------
/.prettierignore:
--------------------------------------------------------------------------------
1 | public/bundle.js
2 | public/bundle.js.map
3 | package-lock.json
4 | package.json
5 |
--------------------------------------------------------------------------------
/.prettierrc.yml:
--------------------------------------------------------------------------------
1 | # printWidth: 80 # 80
2 | # tabWidth: 2 # 2
3 | # useTabs: false # false
4 | semi: false # true
5 | singleQuote: true # false
6 | # trailingComma: none # none | es5 | all
7 | bracketSpacing: false # true
8 | # jsxBracketSameLine: false # false
9 | # arrowParens: avoid # avoid | always
10 |
--------------------------------------------------------------------------------
/.travis.yml:
--------------------------------------------------------------------------------
1 | language: node_js
2 | node_js:
3 | - 14 # uses version 14
4 | services:
5 | - postgresql # starts up postgres
6 | addons:
7 | postgresql: '10' # recent postgres version on Travis
8 | dist: xenial # uses xenial environment
9 | notifications:
10 | email:
11 | on_success: change # default: change (only when going from broken to fixed)
12 | on_failure: always # default: always (which is annoying, as it should be)
13 | install:
14 | - npm ci # faster, goes only from package-lock
15 | before_script:
16 | - psql -c 'create database "boilermaker-test";' -U postgres # remember to change this name if you change it elsewhere (e.g. package.json)
17 | script:
18 | - npm test # test the code
19 | - npm run build-client # make the bundle
20 | # before_deploy:
21 | # - rm -rf node_modules # omit from the tarball, since we skip cleanup
22 | # deploy:
23 | # skip_cleanup: true # prevents travis from deleting the build
24 | # provider: heroku
25 | # app: YOUR-HEROKU-APP-NAME-HERE # see README
26 | # api_key:
27 | # secure: YOUR-***ENCRYPTED***-API-KEY-HERE # see README
28 |
--------------------------------------------------------------------------------
/CHANGELOG.md:
--------------------------------------------------------------------------------
1 | # Updates to Boilermaker
2 |
3 | ## Tuesday, April 9th, 2019
4 |
5 | ### Dependencies
6 |
7 | * axios update to 0.18.0 from 0.15.3
8 | * connect-session-sequelize update to 6.0.0 from 4.1.0
9 | * history update to 4.9.0 from 4.6.3
10 | * morgan update to 1.9.1 from 1.8.1
11 | * passport update to 0.4.0 from 0.3.2
12 | * passport-google-oauth update to 2.0.0 from 1.0.0
13 | * pg update to 7.9.0 from 6.1.2
14 | * prop-types update to 15.7.2 from 15.6.2
15 | * **react-redux update to 5.0.7 from 5.0.2**
16 | * There are some known issues with this and other react packages; will update after some testing
17 | * react-router-dom update to 5.0.0 from 4.3.1
18 | * redux update to 4.0.1 from 3.6.0
19 | * redux-logger update to 3.0.6 from 2.8.1
20 | * sequelize update to 5.2.15 from 4.38.0
21 | * socket.io update to 2.2.0 from 2.1.0
22 |
23 | ### DevDependencies
24 |
25 | * axios-mock-adatper update to 1.16.0 from 1.15.0
26 | * babel-eslint update to 10.0.1 from 8.2.6
27 | * chai update to 4.2.0 from 3.5.0
28 | * enzyme update to 3.9.0 from 3.0.0
29 | * enzyme-adapter-react-16 update to 1.12.1 from 1.0.0
30 | * eslint update to 5.16.0 from 4.19.1
31 | * eslint-config-fullstack update to 6.0.0 from 5.1.0
32 | * eslint-config-prettier update to 4.1.0 from 2.9.0
33 | * husky update to 1.3.1 from 0.14.3
34 | * lint-staged update to 8.1.5 from 7.2.0
35 | * mocha update to 6.1.2 from 5.2.0
36 | * supertest update to 4.0.2 from 3.1.0
37 | * @babel/core update to 7.4.3 from 7.0.0-beta.55
38 | * @babel/plugin-proposal-class-properties update to 7.4.0 from 7.0.0-beta.54
39 | * @babel/plugin-proposal-decorators update to 7.4.0 from 7.0.0-beta.54
40 | * @babel/plugin-proposal-export-namespace-from update to 7.2.0 from 7.0.0-beta.54
41 | * @babel/plugin-proposal-function-sent update to 7.2.0 from 7.0.0-beta.54
42 | * @babel/plugin-proposal-numeric-separator update to 7.2.0 from 7.0.0-beta.54
43 | * @babel/plugin-proposal-throw-expressions update to 7.2.0 from 7.0.0-beta.54
44 | * @babel/plugin-syntax-dynamic-import update to 7.2.0 from 7.0.0-beta.54
45 | * @babel/plugin-syntax-import-meta update to 7.2.0 from 7.0.0-beta.54
46 | * @babel/polyfill update to 7.4.3 from 7.0.0-beta.55
47 | * @babel/preset-env update to 7.4.3 from 7.0.0-beta.55
48 | * @babel/preset-react update to 7.0.0 from 7.0.0-beta.55
49 | * @babel/register update to 7.4.0 from 7.0.0-beta.55
50 | * babel-loader update to 8.0.5 from 8.0.0-beta.4
51 |
52 | `npm i enzyme` to fix lodash dependency: [Prototype Polution](https://www.npmjs.com/advisories/782)
53 |
54 | ## Wednesday, April 10th, 2019
55 |
56 | ### Dependencies
57 |
58 | * react-redux update to 7.0.1 from 5.0.7
59 | * Found out that as long as react- is 16.4+, the updates should be fine
60 | * react update to 16.8.6 from 16.4.2
61 | * react-dom update to 16.8.6 from 16.4.2
62 |
63 | ## Thursday, April 11th, 2019
64 |
65 | ### Dependencies
66 |
67 | * sequelize update to 5.3.1 from 5.2.15
68 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright (c) 2018 Fullstack Academy
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Boilermaker
2 |
3 | _Good things come in pairs_
4 |
5 | Looking to mix up a backend with `express`/`sequelize` and a frontend with
6 | `react`/`redux`? That's `boilermaker`!
7 |
8 | Follow along with the boilerplate workshop to make your own! This canonical
9 | version can serve as a reference, or a starting point. For an in depth
10 | discussion into the code that makes up this repository, see the
11 | [Boilermaker Guided Tour][boilermaker-yt]
12 |
13 | [boilermaker-yt]: https://www.youtube.com/playlist?list=PLx0iOsdUOUmn7D5XL4mRUftn8hvAJGs8H
14 |
15 | ## Setup
16 |
17 | To use this as boilerplate, you'll need to take the following steps:
18 |
19 | * Don't fork or clone this repo! Instead, create a new, empty
20 | directory on your machine and `git init` (or create an empty repo on
21 | Github and clone it to your local machine)
22 | * Run the following commands:
23 |
24 | ```
25 | git remote add boilermaker https://github.com/FullstackAcademy/boilermaker.git
26 | git fetch boilermaker
27 | git merge boilermaker/master
28 | ```
29 |
30 | Why did we do that? Because every once in a while, `boilermaker` may
31 | be updated with additional features or bug fixes, and you can easily
32 | get those changes from now on by entering:
33 |
34 | ```
35 | git fetch boilermaker
36 | git merge boilermaker/master
37 | ```
38 |
39 | ## Customize
40 |
41 | Now that you've got the code, follow these steps to get acclimated:
42 |
43 | * Update project name and description in `package.json` and
44 | `.travis.yml` files
45 | * `npm install`
46 | * Create two postgres databases (`MY_APP_NAME` should match the `name`
47 | parameter in `package.json`):
48 |
49 | ```
50 | export MY_APP_NAME=boilermaker
51 | createdb $MY_APP_NAME
52 | createdb $MY_APP_NAME-test
53 | ```
54 |
55 | * By default, running `npm test` will use `boilermaker-test`, while
56 | regular development uses `boilermaker`
57 | * Create a file called `secrets.js` in the project root
58 | * This file is listed in `.gitignore`, and will _only_ be required
59 | in your _development_ environment
60 | * Its purpose is to attach the secret environment variables that you
61 | will use while developing
62 | * However, it's **very** important that you **not** push it to
63 | Github! Otherwise, _prying eyes_ will find your secret API keys!
64 | * It might look like this:
65 |
66 | ```
67 | process.env.GOOGLE_CLIENT_ID = 'hush hush'
68 | process.env.GOOGLE_CLIENT_SECRET = 'pretty secret'
69 | process.env.GOOGLE_CALLBACK = '/auth/google/callback'
70 | ```
71 |
72 | ### OAuth
73 |
74 | * To use OAuth with Google, complete the steps above with a real client
75 | ID and client secret supplied from Google
76 | * You can get them from the [Google APIs dashboard][google-apis].
77 |
78 | [google-apis]: https://console.developers.google.com/apis/credentials
79 |
80 | ## Linting
81 |
82 | Linters are fundamental to any project. They ensure that your code
83 | has a consistent style, which is critical to writing readable code.
84 |
85 | Boilermaker comes with a working linter (ESLint, with
86 | `eslint-config-fullstack`) "out of the box." However, everyone has
87 | their own style, so we recommend that you and your team work out yours
88 | and stick to it. Any linter rule that you object to can be "turned
89 | off" in `.eslintrc.json`. You may also choose an entirely different
90 | config if you don't like ours:
91 |
92 | * [Standard style guide](https://standardjs.com/)
93 | * [Airbnb style guide](https://github.com/airbnb/javascript)
94 | * [Google style guide](https://google.github.io/styleguide/jsguide.html)
95 |
96 | ## Start
97 |
98 | Running `npm run start-dev` will make great things happen!
99 |
100 | If you want to run the server and/or `webpack` separately, you can also
101 | `npm run start-server` and `npm run build-client`.
102 |
103 | From there, just follow your bliss.
104 |
105 | ## Deployment
106 |
107 | Ready to go world wide? Here's a guide to deployment! There are two
108 | supported ways to deploy in Boilermaker:
109 |
110 | * automatically, via continuous deployment with Travis.
111 | * "manually", from your local machine via the `deploy` script.
112 |
113 | Either way, you'll need to set up your deployment server to start.
114 | The steps below are also covered in the CI/CD workshop.
115 |
116 | ### Heroku
117 |
118 | 1. Set up the [Heroku command line tools][heroku-cli]
119 | 2. `heroku login`
120 | 3. Add a git remote for heroku:
121 |
122 | [heroku-cli]: https://devcenter.heroku.com/articles/heroku-cli
123 |
124 | * **If you are creating a new app...**
125 |
126 | 1. `heroku create` or `heroku create your-app-name` if you have a
127 | name in mind.
128 | 2. `heroku addons:create heroku-postgresql:hobby-dev` to add
129 | ("provision") a postgres database to your heroku dyno
130 |
131 | * **If you already have a Heroku app...**
132 |
133 | 1. `heroku git:remote your-app-name` You'll need to be a
134 | collaborator on the app.
135 |
136 | ### Travis
137 |
138 | _**NOTE**_ that this step assumes that Travis-CI is already testing your code.
139 | Continuous Integration is not about testing per se – it's about _continuously
140 | integrating_ your changes into the live application, instead of periodically
141 | _releasing_ new versions. CI tools can not only test your code, but then
142 | automatically deploy your app. This is known as Continuous Deployment.
143 | Boilermaker comes with a `.travis.yml` configuration almost ready for
144 | continuous deployment; follow these steps to the job.
145 |
146 | 1. Run the following commands to create a new branch:
147 |
148 | ```
149 | git checkout master
150 | git pull
151 | git checkout -b f/travis-deploy
152 | ```
153 |
154 | 2. Run the following script to finish configuring `travis.yml` :
155 | `npm run heroku-token`
156 | This will use your `heroku` CLI (that you configured previously, if
157 | not then see [above](#Heroku)) to generate an authentication token. It
158 | will then use `openssl` to encrypt this token using a public key that
159 | Travis has generated for you. It will then update your `.travis.yml`
160 | file with the encrypted value to be sent with the `secure` key under
161 | the `api_key`.
162 | 3. Run the following commands to commit these changes
163 |
164 | ```
165 | git add .travis.yml
166 | git commit -m 'travis: activate deployment'
167 | git push -u origin f/travis-deploy
168 | ```
169 |
170 | 4. Make a Pull Request for the new branch, get it approved, and merge it into
171 | the master branch.
172 |
173 | _**NOTE**_ that this script depends on your local `origin` Git remote matching
174 | your GitHub URL, and your local `heroku` remote matching the name of your
175 | Heroku app. This is only an issue if you rename your GitHub organization,
176 | repository name or Heroku app name. You can update these values using
177 | `git remote` and its related commands.
178 |
179 | #### Travis CLI
180 |
181 | There is a procedure to complete the above steps by installing the official
182 | [Travis CLI tools][travis-cli]. This requires a recent Ruby, but this step
183 | should not be, strictly speaking, necessary. Only explore this option when the
184 | above has failed.
185 |
186 | [travis-cli]: https://github.com/travis-ci/travis.rb#installation
187 |
188 | That's it! From now on, whenever `master` is updated on GitHub, Travis
189 | will automatically push the app to Heroku for you.
190 |
191 | ### Cody's own deploy script
192 |
193 | Your local copy of the application can be pushed up to Heroku at will,
194 | using Boilermaker's handy deployment script:
195 |
196 | 1. Make sure that all your work is fully committed and merged into your
197 | master branch on Github.
198 | 2. If you currently have an existing branch called "deploy", delete
199 | it now (`git branch -d deploy`). We will use a dummy branch
200 | with the name `deploy` (see below), so and the script below will error if a
201 | branch with that name already exists.
202 | 3. `npm run deploy`
203 | _ this will cause the following commands to happen in order:
204 | _ `git checkout -b deploy`: checks out a new branch called
205 | `deploy`. Note that the name `deploy` here is not magical, but it needs
206 | to match the name of the branch we specify when we push to our `heroku`
207 | remote.
208 | _ `webpack -p`: webpack will run in "production mode"
209 | _ `git add -f public/bundle.js public/bundle.js.map`: "force" add
210 | these files which are listed in `.gitignore`.
211 | _ `git commit --allow-empty -m 'Deploying'`: create a commit, even
212 | if nothing changed
213 | _ `git push --force heroku deploy:master`: push your local
214 | `deploy` branch to the `master` branch on `heroku`
215 | _ `git checkout master`: return to your master branch
216 | _ `git branch -D deploy`: remove the deploy branch
217 |
218 | Now, you should be deployed!
219 |
220 | Why do all of these steps? The big reason is because we don't want our
221 | production server to be cluttered up with dev dependencies like
222 | `webpack`, but at the same time we don't want our development
223 | git-tracking to be cluttered with production build files like
224 | `bundle.js`! By doing these steps, we make sure our development and
225 | production environments both stay nice and clean!
226 |
--------------------------------------------------------------------------------
/client/app.js:
--------------------------------------------------------------------------------
1 | import React from 'react'
2 |
3 | import {Navbar} from './components'
4 | import Routes from './routes'
5 |
6 | const App = () => {
7 | return (
8 |