add githooks for build -- prod

[empeje]

https://github.com/ole-vi/planet/issues/197

How it works:

• when you commit it will try to do ng buil --prod if returns with 0 exit code, it will continue to commit, otherwise not.

[lmmrssa]

@mappuji I see package-lock.json file being added. Could you remove it. It's not required to be added in commit. Changes is only in package.json

[empeje]

I think it is common practice to put update on lock file. Since it has file about our dependency tree so we don't need to fetch tree again when new people doing npm install

What do you think?

[paulbert]

@mappuji We do not include a package.lock in the repository because we are using npm version 3.10.10 on our virtual machines. Package.lock files were introduced with npm version 5. We can consider upgrading, but that should be done in another issue.

A few other things:

• This solution will not work for those of us--and this should be all of us--using vagrant for our development environment. We can write a hook that is similar to to the pre-push hook located in git-hooks instead.
• Also, do we want this as a pre-commit hook or pre-push? We made the decision with linting to make it a pre-push hook so developers could commit locally with errors but anything pushed to GitHub would be clean. We can discuss at the meeting today.

[empeje]

Hi @paulbert

Thank you for the explanation. I'll delete the lock file.
However for the hooks, I suggest it is a pre-commit hook since we want to make sure no one commit in un-buildable state.

[paulbert]

@mappuji Committing an un-buildable state is OK since those changes are only on the developer's local machine. Pushing is where the problem arises and we will have build failure, and avoiding merging these broken builds with the master is the major goal (it's too bad Travis is passing builds that fail).

It's easier to follow PRs if different blocks of changes are spread across multiple commits with clear commit messages. If we have to wait 2+ minutes while commits are confirmed it encourages developers to continue to clump all their changes together and write less helpful messages like "Fix changes". That's why I'd like to have this as a pre push rather than pre commit hook.

[empeje]

@paulbert again, I understand the concern now. Actually my personal default for this kind of hooks is pre-commit, but after reading your explanation I began to understand. After all, you are the one who experience the development flow.

Could you help me where I can put the hooks? or general direction for that.

[paulbert]

Closing this since #227 is working on the same thing