enriquecaballero / branchsite Goto Github PK

The interesting part:

 ✖ Install dependencies using npm
   → spawn yarn ENOENT
   Build static assets using npm
{ Error: spawn yarn ENOENT
    at exports._errnoException (util.js:1026:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:193:32)
    at onErrorNT (internal/child_process.js:359:16)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)
  code: 'ENOENT',
  errno: 'ENOENT',
  syscall: 'spawn yarn',
  path: 'yarn',
  spawnargs: [ 'install' ],
  stdout: '',
  stderr: '',
  failed: true,
  signal: null,
  cmd: 'yarn install',
  timedOut: false,
  killed: false,
  context: {} }
(node:98351) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 5): Error: spawn yarn ENOENT

I'm assuming this is because I don't have Yarn installed. even using --no-yarn helps.

After moving to semantic-release, we can no longer parse out the version number from package.json. We'll have to come up with a way of injecting the current version number during the build process.

commander maintenance is doubtful, maybe consider using meow?

Need to leverage the GH_TOKEN that Travis CI exports to be able to push to GitHub. Need to figure out a secure way of achieving this.

Just using git push might cause problems with some CI's such as Jenkins. Jenkins, for example, always checks out a revision and never exactly master, so its push to needs to explicitly know it's going to HEAD:master before any subtree push.

As of v1.4.0, branchsite allows the user to stage files even when the --no-commit arg is passed in, by using --stage. Should the staging of files happen regardless of --no-commit as default behavior?

It might be a good idea to improve the gh-pages workflow by matching those done by others via the use of deploy keys

References:

• https://djw8605.github.io/2017/02/08/deploying-docs-on-github-with-travisci/
• https://gist.github.com/domenic/ec8b0fc8ab45f39403dd
• http://stackoverflow.com/questions/23277391/how-to-publish-to-github-pages-from-travis-ci
• http://ricostacruz.com/cheatsheets/travis-gh-pages.html

Some libraries bump up the version number in package.json and create a CHANGELOG.md file based off commit history, commiting them in the process (see standard-version). Would be ideal to allow the user to amend that last (tagged) commit (without losing the original tag) instead of just creating a brand new commit.

Caporal is now at 1.3.0, and npm audit reports 3 vulnerabilities in branchsite because of a nested dependency (in [email protected]) of older lodash in cli-table2, which was mitigated by caporal. switching to cli-table3

The devDependency uglify-js was updated from 3.4.9 to 3.4.10.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

uglify-js is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Version 3.4.2 of lint-staged just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As lint-staged is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

The README is pretty generic right now -- has plenty of room to grow

Need to come up with proper testing for this module...