|
1 | 1 | # Big Spaceship Coding Standards
|
| 2 | + |
2 | 3 | Coding standards for the Big Spaceship Technology Team
|
3 | 4 |
|
4 | 5 | ## General Practice
|
5 |
| -* Soft Tabs (2 spaces) |
| 6 | + |
| 7 | +- Soft Tabs (2 spaces) |
| 8 | +- Comments |
| 9 | + |
| 10 | +### HTML |
| 11 | + |
| 12 | +- Alt tags on all images |
| 13 | + |
| 14 | +### CSS/SCSS |
| 15 | + |
| 16 | +- SCSS preferred |
| 17 | +- 3 level nesting limit |
| 18 | +- Custom SCSS variables file (media queries and color pallete) |
| 19 | +- Autoprefixer |
| 20 | +- Make use of mixins for repeated styles across components |
| 21 | + |
| 22 | +### Javascript |
| 23 | + |
| 24 | +- AirBnb EsLint |
6 | 25 |
|
7 | 26 | ## Project Setup
|
8 |
| -* Use BSS-CLI Tool |
9 |
| -* Create a GitHub Repo with Big Spaceship Team Admin Access |
| 27 | + |
| 28 | +- Use BSS-CLI Tool |
| 29 | +- Create a GitHub Repo with Big Spaceship Team Admin Access |
10 | 30 |
|
11 | 31 | ## Code Formatting
|
12 |
| -* Prettier |
13 |
| -* Custom Media Queries |
| 32 | + |
| 33 | +- Prettier |
| 34 | +- Custom Media Queries |
14 | 35 |
|
15 | 36 | ## Git Workflow
|
16 |
| -* Git Flow as a Reliable Version Control Model |
| 37 | + |
| 38 | +- Git Flow as a Reliable Version Control Model |
17 | 39 |
|
18 | 40 | Please try to use the standard Git Flow control model in which we use a combination of the following branches:
|
19 | 41 |
|
20 |
| - | | | |
21 |
| - |----------------|-------------------------------| |
22 |
| - |Master |Only contains production ready code. Commits to this branch should only come from either a release or a hotfix branch.| |
23 |
| - |Develop |One source of truth from which all feature branches should be created and checked out from.| |
24 |
| - |Feature |Follows a standard naming convention of `feature/featureName`. All new development is built here.| |
25 |
| - |Release |Branch that gets deployed to a staging environment for QA, and where all QA fixes should be done. If the team is bigger, a feature branch can be spun off this to make all required QA changes.| |
26 |
| - |Hotfix |Only emergency fixes off the master branch. Follows a similar naming convention as a feature branch. After it is done please make sure to merge it both into master and develop.| |
| 42 | + | | | |
| 43 | + | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
| 44 | + | Master | Only contains production ready code. Commits to this branch should only come from either a release or a hotfix branch. | |
| 45 | + | Develop | One source of truth from which all feature branches should be created and checked out from. | |
| 46 | + | Feature | Follows a standard naming convention of `feature/featureName`. All new development is built here. | |
| 47 | + | Release | Branch that gets deployed to a staging environment for QA, and where all QA fixes should be done. If the team is bigger, a feature branch can be spun off this to make all required QA changes. | |
| 48 | + | Hotfix | Only emergency fixes off the master branch. Follows a similar naming convention as a feature branch. After it is done please make sure to merge it both into master and develop. | |
27 | 49 |
|
28 | 50 | Bellow if a quick flow model:
|
29 | 51 |
|
30 | 52 | 
|
31 | 53 |
|
32 | 54 | Please remember to remove feature and hotfix branches either after a PR or after push to Prod.
|
33 | 55 |
|
34 |
| -* [Feature Branch Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) |
35 |
| -* [Commit Message Guidelines](https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53) |
36 |
| -* Pull Requests for each feature to be merged reviewed by other members of the team. |
37 |
| -* Git versioning: |
38 |
| - * We should attempt to follow the Semver versioning rules when tagging our projects for release. |
39 |
| - * When using the BSS CLI tool or starting a new NPM project please make sure to set the version in package.json to 3 digits (1.0.0). |
40 |
| - |
41 |
| - | Status | Stage | Rule | Example | |
42 |
| - | -- | -- | -- | -- | |
43 |
| - | Init Release | New Project | Should begin with ver 1 | 1.0.0 | |
44 |
| - | Bug fixes, minor changes | Patch release | +1 to the third digit | 1.0.1 | |
45 |
| - | Major changes that are build on the existing framework/codebase | Minor release | +1 to the second digit | 1.1.1 | |
46 |
| - | Major changes that require rebuilding existing features, change or major updates to the underlaying frameworks | Major release | +1 to the first digit | 2.1.1 | |
47 |
| - |
48 |
| - * Also please keep in mind to make sure that the release versions in github and package.json are in sync. |
| 56 | +- [Feature Branch Workflow](https://www.atlassian.com/git/tutorials/comparing-workflows#feature-branch-workflow) |
| 57 | +- [Commit Message Guidelines](https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53) |
| 58 | +- Pull Requests for each feature to be merged reviewed by other members of the team. |
| 59 | +- Git versioning: |
| 60 | + |
| 61 | + - We should attempt to follow the Semver versioning rules when tagging our projects for release. |
| 62 | + - When using the BSS CLI tool or starting a new NPM project please make sure to set the version in package.json to 3 digits (1.0.0). |
| 63 | + |
| 64 | + | Status | Stage | Rule | Example | |
| 65 | + | -------------------------------------------------------------------------------------------------------------- | ------------- | ----------------------- | ------- | |
| 66 | + | Init Release | New Project | Should begin with ver 1 | 1.0.0 | |
| 67 | + | Bug fixes, minor changes | Patch release | +1 to the third digit | 1.0.1 | |
| 68 | + | Major changes that are build on the existing framework/codebase | Minor release | +1 to the second digit | 1.1.1 | |
| 69 | + | Major changes that require rebuilding existing features, change or major updates to the underlaying frameworks | Major release | +1 to the first digit | 2.1.1 | |
| 70 | + |
| 71 | + - Also please keep in mind to make sure that the release versions in github and package.json are in sync. |
49 | 72 |
|
50 | 73 | ## Linting
|
51 |
| -* [AirBnB EsLint](https://github.com/bigspaceship/javascript) |
| 74 | + |
| 75 | +- [AirBnB EsLint](https://github.com/bigspaceship/javascript) |
52 | 76 |
|
53 | 77 | ## Testing
|
54 |
| -* [Jest](https://facebook.github.io/jest/) |
| 78 | + |
| 79 | +- [Jest](https://facebook.github.io/jest/) |
55 | 80 |
|
56 | 81 | ## Permissable Libraries
|
57 |
| -* [Vue](https://vuejs.org/) |
58 |
| -* [React](https://reactjs.org/) |
59 |
| -* [Next.js](https://github.com/zeit/next.js/) |
| 82 | + |
| 83 | +- [Vue](https://vuejs.org/) |
| 84 | +- [React](https://reactjs.org/) |
| 85 | +- [Next.js](https://github.com/zeit/next.js/) |
60 | 86 |
|
61 | 87 | ## Recommended Tools
|
62 |
| -* [Webpack](https://webpack.js.org/) |
63 |
| -* [Babel](https://babeljs.io/) |
| 88 | + |
| 89 | +- [Webpack](https://webpack.js.org/) |
| 90 | +- [Babel](https://babeljs.io/) |
64 | 91 |
|
65 | 92 | ## Files to Include in all projects
|
66 |
| -* Custom Media Query file |
67 |
| -* .prettierrc |
68 |
| -* .babelrc |
69 |
| -* .eslintrc |
| 93 | + |
| 94 | +- variables.scss |
| 95 | +- .babelrc |
| 96 | +- .eslintrc |
70 | 97 |
|
71 | 98 | ## Deployment Practice
|
72 |
| -* Use environment variables for api secrets and tokens |
73 |
| -* Minify and Uglify code and build process |
| 99 | + |
| 100 | +- Use environment variables for api secrets and tokens |
| 101 | +- Minify and Uglify code and build process |
74 | 102 |
|
75 | 103 | ## How to improve this document
|
| 104 | + |
76 | 105 | Please Create an Issue relating to which section of this document you would like altered and what you would like altered within the section. We can discuss potential changes within the issue and once agreed upon a Pull Request can be made.
|
0 commit comments