An AngularJS 1.5 web app that runs fully client side (served as static assets), with a local development and build stack for easy development, testing and building, as well as communicating with the backend API server (via proxying /api
calls from the browser).
Note: You can receive memory issues when running the tests in a docker container.
- I would recommend 6GB memory for using over 4 GB for docker.
- Alternatively, run the test in the local environment.
yarn run test
nave
is a useful way to manage multiple/specific versions of NodeJS.
I would recommend using nvm
instead. To setup, install nvm.
Then run:
nvm install 6.9.1
Then run afterwards or any time you need to use node 6.9.1:
nvm use 6.9.1
Alternatively use the following:
To set up:
npm install -g nave
nave use 6.9.1
NOTE: you'll then need to run nave use 6.9.1
every time you start up a new shell.
Yarn
provides a more deterministic, safe and reliable mechanism for NodeJS package management (substitute for npm
).
The simplest way to set this up is: npm install -g [email protected]
though see the install docs for details on potentially better ways. Note that Yarn needs to be available for the version of NodeJS you set up above.
yarn
NOTE: If you're experiencing issues pulling dependencies from github you might need to update your git configuration:
git config --global url."https://".insteadOf git://
yarn run serve
– runs a local dev server to serve the app in dev mode (with auto reloading)yarn run build
– builds the optimized version of the app for production environments (in/dist
)yarn run serve:dist
– runs a local server to serve the optimized version of the app (runs the build in the process)yarn run test
– runs testsyarn run test:auto
– runs tests and then reruns tests automatically on changes
See all available tasks in the scripts
section of package.json
.
The structure of this app, and the coding guidelines to work on it, are largely based on:
- https://github.com/toddmotto/angular-styleguide
- https://github.com/johnpapa/angular-styleguide/tree/master/a1
Important exceptions to the above styleguides:
- When defining an AngularJS
component
ordirective
, place it's correspondingController
function (assuming it has one) in the same file. This is a conscious decision to keep the logic in components/directives as close as possible to the declaration. - All application routes are defined in one file:
src/app/app.routes.js
.
- The various
app.*.js
files insrc/app
set up everything needed for the overall AngularJS app to run, including any module dependencies, runtime config, routes, constants, etc.- The
app.module.js
is the main "assembly" of the app, and is also where app-wide constants are defined.
- The
- We break down the app as much as possible into AngularJS modules – in theory, each module could be tested in isolation.
- We have one top level
app
module that assembles everything together (as mentioned above). - Each individual section – usually a routable part – of the app has it's own folder in
src/app
(e.g.src/app/home
) and has it's own module definition in<section-name>.module.js
where all of it's dependencies are described, and all of it's children components, directives, services, factories, etc. are assmebled into the module. Everything needed for this section of app should go in this folder (and broken down into further modules within this folder, if needed). - A special
app/shared
module is used for shared code across the app. You can register stuff directly within this module, or in further modules inside of theapp/shared
folder (e.g.app/shared/auth
). - The individual files that provide AngularJS components, directives, services, factories, etc. don't actually know they are AngularJS specific things, as such – they are just functions and objects that make use of AngularJS' conventions, dependency injection and structures, and only get registered in their relevant parent's
<foo>.module.js
file in to the AngularJS runtime.
- We have one top level
- For CSS we use SASS because it's awesome.
- The
src/app/app.scss
file provides app level styling. - Individual app sections and shared modules should have their own
<foo>.scss
file, within their folders, if needed. The dev server and build pipeline will automatically pick these up when building the styles.
- The