Conservative and basic Gulp module for enterprise Angular 1 projects.
Why should you use this rather conservative module to power your Angular 1 build process?
You shouldn't in an ideal world were you could do everything as you please and move on to webpack and so on. However in enterprise environments there are often restrictions (e.g. downloading binaries on your build server), other requirements (e.g. stability and documentation) or your colleagues are just not up to the churn.
If you look at other Gulp modules, you will find them often to be convoluted and to be showcases of what you could do if you push the limits.
This module aims to be different: Basic, conservative and documented.
This module is ideally customer-based, i.e. a customer agrees on a default stack for their common projects and the build tooling is adapted accordingly. Of course it could also be used as project-based module for one ore more Angular applications.
I used my initials as prefix in order to emphasize the high probability for you to customize the module based on your customer/company/project. So change it to your customer/project prefix and do the necessary adaptions.
A typical workflow for a fork would be to:
These are the assumptions about the stack if you just want to use the module out-of-the box.
The assumption and best practice is to do consumer-driven API- and E2E-tests in a separate project.
In alphabetical order.
This has rather huge advantages and should be preferred to the integrated folder. There are three possibilities here:
npm i -D akGulpwhich isn't recommended.
akGulpand now have an adapted version in own repository. In this case you will probably need to use the repository URL in the
package.json. This is not recommended since installations will take time, there will be no caching and no semver. Also you would probably need an SSH connection to the repository (and therefore the server) which is often an issue for the ops.
Here you can overwrite the paths if your folder structure differs or specify additional and different options for the gulp plugins.
The only required entry is the
moduleName which is used for the partials as Angular module name and is the same as the root module in your
moduleexports =moduleName: 'my';
paths properties overwrite the properties in
path.js and the
consts properties overwrite the properties in
You can define you own tasks or overwrite existing ones but it must at least have the following:
'use strict';var akGulp = ;var gulp = ;var config = ;var karma = ;configkarma = karma;;
To overwrite or create a task you define it in this file on the gulp object before you pass it.
This is the configuration for Karma and is required to be a valid module that exports an object. There are two major differences between this custom karma configuration and the default
kamra.conf.js you might know. Dependencies and browsers have to specified with a special syntax. Everything else is like the default Karma configuration.
Dependencies which would normally just be the
files property in Karma must be specified with the
deps property since
are added automatically. Here's an example:
'use strict';moduleexports =deps:'node_modules/angular/angular.js''node_modules/angular-mocks/angular-mocks.js''test/setup.js';
Browsers which would normally just be an array of strings are separated into
production for your CI and
development for your local environment. Here an example:
browsers:production: 'IE'development: 'Chrome'
Possible values are
The default minimal folder structure of the project is:
Have a look at
paths.js if you want to overwrite it.
This is the preferred approach if you don't plan on heavily modularizing your applications.
You will need to structure your project according to the previous section and make following adaptions.
lib-folder to your project folder and rename it to
var akGulp = require('./lib/index');
dependenciesfrom this module to the
devDependenciesand remove duplicates.
For an example see akSkeleton.
This is a description of commonly used tasks during development. An extensive list and documentation can be found at the respective website. The same documentation can also be generated by
npm run doc.
gulp (defaults to
gulp dev): Launches a server hosting and watching the development files. The server reacts on changes on the development files and automatically does script injection if a new file is found or runs the preprocessor, tests and linter on changes.
gulp build: After successfully running the tests it builds the distribution which produces following folder structure:
There's also the temporary folder which is used for development and intermediary files:
The production flag is a environment variable which name is defined in
PRODUCTION) that makes pipes break on lint and plugin errors. It also enables the usage of different test browsers.
Local development is done with
npm link in this projects folder and then linking it via
npm link ak-gulp into the implementer's project folder.
There are three npm scripts:
npm run clean: Deletes
npm run lint: Lints
npm run doc: Generates the documentation to
Here are several constants like plugin options or the production flag.
This is the entry point of the module, everything gets set up here.
The default path structure as shown above. Also there is an array which allows to specify unhandled assets via negative glob.