|
| 1 | +_model: page |
| 2 | +--- |
| 3 | +_template: page-with-toc.html |
| 4 | +--- |
| 5 | +title: JavaScript Guidelines |
| 6 | +--- |
| 7 | +description: |
| 8 | + |
| 9 | +These JavaScript Guidelines (style guide) help the community to focus on the intent of the code and work together with a minimum of friction. |
| 10 | +--- |
| 11 | +body: |
| 12 | + |
| 13 | +## Purpose |
| 14 | + |
| 15 | +These JavaScript Guidelines help developers who are new to the community and want to make a contribution to the Creative Commons open-source ecosystem. |
| 16 | + |
| 17 | +## Philosophy |
| 18 | +A few philosophical guidelines can stand in place of a thousand narrow rules. |
| 19 | + |
| 20 | +### Stewardship |
| 21 | + |
| 22 | +> Build for longevity and maturity. |
| 23 | +
|
| 24 | +Choose an existing framework and set of tools and use them to make what matters to you. Avoiding creating a bespoke framework when a current framework would get you further down the road. |
| 25 | + |
| 26 | +When choosing tools and technologies, keep an eye towards mature projects and standards built to last many years. Find projects that extend existing standards and ways of working. |
| 27 | + |
| 28 | +### Focus |
| 29 | + |
| 30 | +> Choose the right level of abstraction and best use of time. |
| 31 | +
|
| 32 | +When developing, it is easy to find ourselves in layers of technology that are not directly contributing to our goals. For example, spending inordinate time with build tool configurations or type definitions instead of building features and getting user feedback. Choose tools that get out of the way and transparently support your work, creating what matters. |
| 33 | + |
| 34 | +### Maintainability |
| 35 | + |
| 36 | +> Write clean and conventional code. |
| 37 | +
|
| 38 | +Code is read more often than it is written. Code is written for humans, not machines. As such, we can do ourselves a favor by making our code as reader-friendly as possible. Follow [clean code guidelines](https://github.com/ryanmcdermott/clean-code-javascript) as well as established development patterns. |
| 39 | + |
| 40 | +## Pragmatics |
| 41 | + |
| 42 | +The following sections outline how we've put the philosophy into action. See the [creativecommons/chooser](https://github.com/creativecommons/chooser) project for an example of how we have applied the recommendations below. |
| 43 | + |
| 44 | +### Code formatting |
| 45 | + |
| 46 | +We adopt existing code formatting standards. To this end, all JavaScript code must be formatted using [Prettier][Prettier], *an opinionated code formatter*. We also use [eslint][eslint] to handle cases that Prettier may overlook. |
| 47 | + |
| 48 | +[eslint]: https://eslint.org/ |
| 49 | +[Prettier]: https://prettier.io/ |
| 50 | + |
| 51 | +### Development environment |
| 52 | + |
| 53 | +We use `npm` to manage development dependencies. Each project should have a `package.json` with dependencies and scripts for running, linting, testing, and deploying the project (where possible). |
| 54 | + |
| 55 | +### Development framework |
| 56 | + |
| 57 | +We use [Vue.js][Vue] as our primary JavaScript development framework. Vue provides a ready-made toolkit that covers many development needs and extends on long-standing web development conventions. |
| 58 | + |
| 59 | +[Vue]: https://vuejs.org/ |
0 commit comments