This monorepo follows the alle monorepo management and publishing pattern.
All interactions with it are made through custom scripts and clever folder structures.
Builds are handled internally by a script that outputs two versions of the modules. One that's in the
CommonJS and one in
This script is exposed via the
npm run build command which will build each individual module in:
All individual packages also export and ES Modules build (along with Flow types). This is most likely to be used if you want to tree-shake your bundle.
To use them, just append
/es to the end of the package name when importing:
import software from '@core/purser-software/es'; await software.create();
Also, if you use Flow for type declarations inside your project, it will automatically pick up the required (optional) arguments and they're expected type.
It's most likely that you'll use
eslint via your editor / IDE, but just in case you don't, there are a couple of scripts set up to do this manually:
npm run lint
This will lint all the files inside the
src folder and log any errors or warnings.
npm run lint:fix
This script will lint files in the
src directory and also try to fix any problems it encounters. (Makes use of
If there's a error it cannot fix, it will log it to the console.
This project makes use of the
flow system of types declaration.
As above with
eslint this project expects your editor or IDE to show you warning or errors in real-time. But if that's not an option you can do it manually:
npm run flow
Will check the
src folder for any files using the
@flow pragma (It runs
flow status under the hood) and it will also start the
daemon if it isn't already running.
npm run glow
glow is just a wrapper for
flow but with a nicer console output. Use this if you want to make sense of your
npm run flow:check
This is left in as a legacy, in case
flow status doesn't work on your system. This is slower and will not work with
glow but you can be certain that it will parse all your files.
Committing changes to
git will trigger two commit hooks that will ensure your code follows the coding style guidelines set forth by
The first check will run
eslint with the
The second check will be
flow, but using the
glow output formatting.
After these two steps, the project will auto-run the
git add command.
jest is set up as the default test runner for this project.
You can run the following test commands that were set up as
npm run testmakes a simple pass and runs all the tests
npm run test:watchwill watch the source folder and re-run tests on file change
A note on
You may run into trouble running
npm run test:watch, which will throw and error along the lines of:
This should mean that there's no space left on the target, but it this case it actually means your system is using too many file watchers.
This can be fixed by increasing that number (warning:
sudo permissions required for this, as we change system settings):
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Circle CI handles this project's builds. It has two workflows set up: one for commit pushed, and one that it scheduled to run during the night.
The commit workflow will trigger every time you push to a branch. If that branch push was triggered by
greenkeeper it will build it, and if it succeeds it will re-push with the updated
npm run lockfile and build again.
The nightly build workflow will run every night at 4 AM and will build the latest changes added to the
This project makes use of
greenkeeper for dependency management.
If a new version of a package is found (either public or private scoped) it will create a new branch with the package change and try to build it. If the build succeeds it will push changes to the
npm run lockfile and re-build again.
When the builds succeeds one of two things will happen: if the package update was to a in-range version, the branch will be deleted (this is by design, as the package will be updated to this version when you reinstall `nodemodules`). If the package update was out of range _(or one of the two previous builds failed) than a PR will be created so that it can be reviewed and fixed.
Questions? Problems? Existential dilemmas? We’re here to help!
Improve this doc.
All improvements to documentation are welcome and encouraged. Submit a PR for documentation on GitHub.