Use yarn instead of npm

This commit is contained in:
Tom Raithel
2017-11-22 13:42:39 +01:00
parent 8182c9a5d5
commit 178f6e92fc
5 changed files with 46 additions and 27 deletions

View File

@@ -1,7 +1,7 @@
language: node_js
node_js: node
install: npm install
script: npm run build
install: yarn install
script: yarn build
deploy:
provider: s3
access_key_id:

View File

@@ -7,8 +7,8 @@ A static site generator for AOE Technology Radar
```
> git clone git@github.com:AOEpeople/aoe_technology_radar.git
> cd aoe_technology_radar
> npm install
> npm run watch
> yarn install
> yarn watch
```
_A new [browser tab](http://127.0.0.1:8080/techradar) should open up - wait

View File

@@ -4,12 +4,16 @@
"description": "",
"main": "index.js",
"scripts": {
"build": "npm run clean && npm run build:pages && npm run build:jsprod && npm run build:css && npm run build:assets",
"build:all": "npm run build",
"build":
"yarn clean && yarn build:pages && yarn build:jsprod && yarn build:css && yarn build:assets",
"build:all": "yarn build",
"build:pages": "cross-env RENDER_MODE=server babel-node ./tasks/build.js",
"build:js": "cross-env RENDER_MODE=client webpack --config webpack.config.js",
"build:jsprod": "cross-env RENDER_MODE=client webpack -p --config webpack.config.js",
"build:css": "postcss -c postcss.config.json -o dist/techradar/assets/css/styles.css styles/main.css",
"build:js":
"cross-env RENDER_MODE=client webpack --config webpack.config.js",
"build:jsprod":
"cross-env RENDER_MODE=client webpack -p --config webpack.config.js",
"build:css":
"postcss -c postcss.config.json -o dist/techradar/assets/css/styles.css styles/main.css",
"build:assets": "babel-node ./tasks/assets.js",
"watch": "babel-node ./tasks/watch.js",
"clean": "babel-node ./tasks/clean.js",

View File

@@ -2,21 +2,38 @@
title: "Pin external dependencies"
ring: adopt
quadrant: methods-and-patterns
---
A lot of applications have dependencies on other modules or components. We have used different approaches regarding how and when these dependencies are resolved and have agreed on using a method we call "Pin (External) dependencies".
This is especially relevant for script languages, where the dependency management references the code and not immutable prebuild binaries - and therefore resolves the complete transient dependencies on the fly.
A lot of applications have dependencies on other modules or components. We have
used different approaches regarding how and when these dependencies are resolved
and have agreed on using a method we call "Pin (External) dependencies".
This is especially relevant for script languages, where the dependency
management references the code and not immutable prebuild binaries - and
therefore resolves the complete transient dependencies on the fly.
Most of these package- or dependency management solutions support two artefacts:
* a semantic dependency definition. This defines the compatible versions of the required dependencies. (Composer: composer.json / NPM: package.json)
* a lock file defining the exact revisions of the dependencies and the transient dependencies (dependencies of dependencies). This is created after running the tool. (Composer: composer.lock / NPM: npm-shrinkwrap.json).
* a semantic dependency definition. This defines the compatible versions of the
required dependencies. (Composer: composer.json / NPM: package.json)
* a lock file defining the exact revisions of the dependencies and the transient
dependencies (dependencies of dependencies). This is created after running the
tool. (Composer: composer.lock / NPM: npm-shrinkwrap.json / yarn: yarn.lock).
We suggest the following:
* Keep the dependency definition AND the lock file in version control. This ensures that chained dependencies are also locked and you have changes of that file visible in your version control commit history. This helps finding issues or bugs that might relate to unintended updates in external modules or transient dependencies.
* Build Step: The application build step should use the the pinned versions (with the help of the lock file) to ensure that the same revisions of the dependent packages are used.
* It's also suggested to use local or central caches for the retrieval of packages. (E.g. [artifactory as composer and npm cache](/platforms-and-aoe-services/artifactory.html))
* Keep the dependency definition AND the lock file in version control. This
ensures that chained dependencies are also locked and you have changes of that
file visible in your version control commit history. This helps finding issues
or bugs that might relate to unintended updates in external modules or
transient dependencies.
* Build Step: The application build step should use the the pinned versions
(with the help of the lock file) to ensure that the same revisions of the
dependent packages are used.
* It's also suggested to use local or central caches for the retrieval of
packages. (E.g.
[artifactory as composer and npm cache](/platforms-and-aoe-services/artifactory.html))
For updating of dependencies define a process in the team. This can either be done on the dev-system or in a seperate automated CI job - both resulting in updated dependency definitions in the applications VCS.
For updating of dependencies define a process in the team. This can either be
done on the dev-system or in a seperate automated CI job - both resulting in
updated dependency definitions in the applications VCS.

View File

@@ -11,23 +11,21 @@ import {
relativePath,
} from '../common/file';
const runBuild = (name) => (
exec(`npm run build:${name}`, (error, stdout, stderr) => {
const runBuild = name =>
exec(`yarn run build:${name}`, (error, stdout, stderr) => {
if (error) {
console.error(`exec error: ${error}`);
return;
}
console.log(stdout);
console.error(stderr);
})
);
});
const watchBuild = (name) => (eventType, fileName) => runBuild(name);
const watchBuild = name => (eventType, fileName) => runBuild(name);
const options = {
recursive: true,
}
};
runBuild('all');