This project is a boilerplate application with two views using AngularJS 1.x, Typescript, webpack, and NodeJS.
To get you started you can simply clone the angular-boilerplate-typescript-webpack
repository and install the dependencies:
You need git to clone the angular-boilerplate-typescript-webpack
repository. You can get git from here.
You will need NodeJS and npm installed.
Clone the angular-boilerplate-typescript-webpack
repository using git:
git clone https://github.com/anthonyclifton/angular-boilerplate-typescript-webpack.git angular-boilerplate-typescript-webpack
cd angular-boilerplate-typescript-webpack
If you just want to start a new project without the angular-boilerplate-typescript-webpack
commit history then you can do:
git clone --depth=1 https://github.com/anthonyclifton/angular-boilerplate-typescript-webpack.git <your-project-name>
The depth=1
tells git to only pull down one commit worth of historical data.
We have two kinds of dependencies in this project: tools and Angular framework code. The tools help us manage and test the application.
- We get the tools we depend upon via
npm
, the Node package manager. - In order to run the end-to-end tests, you will also need to have the Java Development Kit (JDK) installed on your machine. Check out the section on end-to-end testing for more info.
We have preconfigured npm
to automatically get dependencies so we can simply do:
npm install
You will end up with the following directory:
node_modules
- contains the npm packages for the tools we need
We have preconfigured the project with a simple development web server. The simplest way to start this server is:
npm start
You can browse to the app at localhost:8000
.
app/ --> all of the source files for the application
app.css --> default stylesheet
components/ --> all app specific modules
version/ --> version related components
version.js --> version module declaration and basic "version" value service
version_test.js --> "version" value service tests
version-directive.js --> custom directive that returns the current app version
version-directive_test.js --> version directive tests
interpolate-filter.js --> custom interpolation filter
interpolate-filter_test.js --> interpolate filter tests
view1/ --> the view1 view template and logic
view1.html --> the partial template
view1.js --> the controller logic
view1_test.js --> tests of the controller
view2/ --> the view2 view template and logic
view2.html --> the partial template
view2.js --> the controller logic
view2_test.js --> tests of the controller
app.js --> main application module
index.html --> app layout file (the main html template file of the app)
index-async.html --> just like index.html, but loads js files asynchronously
karma.conf.js --> config file for running unit tests with Karma
e2e-tests/ --> end-to-end tests
protractor-conf.js --> Protractor config file
scenarios.js --> end-to-end scenarios to be run by Protractor
There are two kinds of tests: Unit tests and end-to-end (protractor) tests.
The app comes with some example unit tests. These are written in Jasmine, which we run with the Karma test runner. We provide a Karma configuration file to run them.
- The configuration is found at
karma.conf.js
. - The unit tests are found in
test/unit
.
The easiest way to run the unit tests is to use the supplied npm script:
npm test
This script will start the Karma test runner to execute the unit tests. Moreover, Karma will start watching the source and test files for changes and then re-run the tests whenever any of them changes. This is the recommended strategy; if your unit tests are being run every time you save a file then you receive instant feedback on any changes that break the expected code functionality.
You can also ask Karma to do a single run of the tests and then exit. This is useful if you want to check that a particular version of the code is operating as expected. The project contains a predefined script to do this:
npm run test-single-run
The boilerplate app comes with end-to-end tests, again written in Jasmine. These tests are run with the Protractor End-to-End test runner. It uses native events and has special features for Angular applications.
- The configuration is found at
e2e-tests/protractor-conf.js
. - The end-to-end tests are found in
tests/e2e
.
Protractor simulates interaction with our web app and verifies that the application responds correctly. Therefore, our web server needs to be serving up the application, so that Protractor can interact with it.
Before starting Protractor, open a separate terminal window and run:
npm start
In addition, since Protractor is built upon WebDriver, we need to ensure that it is installed and up-to-date. The project is configured to do this automatically before running the end-to-end tests, so you don't need to worry about it. If you want to manually update the WebDriver, you can run:
npm run update-webdriver
Once you have ensured that the development web server hosting our application is up and running, you can run the end-to-end tests using the supplied npm script:
npm run integration
This script will execute the end-to-end tests against the application being hosted on the development server.
Note:
Under the hood, Protractor uses the Selenium Standalone Server, which in turn requires
the Java Development Kit (JDK) to be installed on your local machine. Check this by running
java -version
from the command line.
If JDK is not already installed, you can download it here.
Since the Angular framework library code and tools are acquired through package managers (npm) you can use these tools to easily update the dependencies. Simply run the preconfigured script:
npm run update-deps
This will call npm update
, which in turn will find and install the latest
versions that match the version ranges specified in the package.json
file
respectively.
While Angular is client-side-only technology and it is possible to create Angular web apps that
do not require a backend server at all, we recommend serving the project files using a local
web server during development to avoid issues with security restrictions (sandbox) in browsers. The
sandbox implementation varies between browsers, but quite often prevents things like cookies, XHR,
etc to function properly when an HTML page is opened via the file://
scheme instead of http://
.
This really depends on how complex your app is and the overall infrastructure of your system, but
the general rule is that all you need in production are the files under the app/
directory.
Everything else should be omitted.
Angular apps are really just a bunch of static HTML, CSS and JavaScript files that need to be hosted somewhere they can be accessed by browsers.
If your Angular app is talking to the backend server via XHR or other means, you need to figure out what is the best way to host the static files to comply with the same origin policy if applicable. Usually this is done by hosting the files by the backend server or through reverse-proxying the backend server(s) and web server(s).
For more information on AngularJS please check out angularjs.org.