What can i do ? All new devs asks that.
We start quickly, we start well !
First day and first spring! First we will do peer programming to create a new module - a library of mongoose models. Peer programming, it is cool! To integrate a new dev, it is a method extremely efficient. The “old” dev can share his knowledges about the previous projects and the team’s work’s methods. The new dev isn’t lost, learn to know a member of his new team and can adapt more easily to his new work’s environment. Communicate, exchange about the problems has a synergistic effect and solutions come more quickly. But it’s not the ultimate work’s method. Everyone learn at his own pace, his reading’s speed, it’s not easy to work with the same rhythm and it can be frustrating to wait each other. Some time, everyone want to check a different way to do something. On the long term, I imagine, it could be frustrating to atomically share his own little wings. First issue: create a repository. And Matthieu, our favorite CTO, has a very precise idea about how do that! He wants solid, maintainable and sexy.
Matthieu wants sexy and ES6 !
No problem, we install ESLint. It’s thrown ES6’s syntax with clear messages and indicates the wrong import’s way ! Wonderfull. But, in this case, the message is deceitful. For exemple, we tryed to do an intern library and the linter asked us to make a module… Little lost of time but except that, it’s a great tool. In this article, i purpose you to speak about following subject : ES6, node.js, babel, gulp, test with mocha implementation, chai, coverage, istanbul, git
But all ES6’s functionalities aren’t supported by node and even less by his modules…
Fortunately, babel’s documentation is a really good feature. We install Babel globally, we create the
.babelrc for the options, we add the polyfill and let’s go ! We could ask to Babel to compile our ES6 sexy after each file’s edition. But we are to lazy and it should be to tedious… Quickly implement Gulp! We install the module. We create the
gulfile.js. We add a folder /tasks. And create our first task:
babel.task.js whose only job is to compile, in a folder
/dist, our files
src/**/*.js after each save. Great, it works… No. Of course, Gulp doesn’t like ES6… Fortunately, the Babel’s doc is top and propose a module easely to use, gulp-babel. It works ! Matthieu wants maintainability and what’s more maintainable that a well documented project ? Let’s go to redact a README with 4000 lines… Or implement easely, quickly and efficiently the module jsdoc3.
And because we are really lazy, we ask to gulp to edit the doc after each edition. A really magical tool.
To continue, we implement our tests with mocha and chai. We create a folder /test and a file.test.js for each file to testing (currently, for each model). And our first test thrown a beautiful error… Mocha doesn’t like ES6… Ho Bale, how i like you doc! After the module gulp-mocha installed, the command write in a package.json’s script, everything work very well. But we want really to do the best, so we install the coverage. To do that, we implement instanbul and… It doesn’t work ! Nobody likes ES6 except us. Fortunately, we are not alone and a module,
gulp-babel-istanbul, exists in npm. Wonderfull, everything works, everything is sexy. But in Umanlife we are perfectionist (just enough) and we need a last control: the git’s hooks. A quick search with the most known search engine and we implement husky. We edit the package.json with the scripts
prepush with the command
gulp lint && gulp test --require babel-polyfill --compilers js:babel-register, we add a
eslint.failAfterError() in babel.task.js and… Ho God! before each commit or push, eslint check if our code is ok, mocha check if our code does his job!
And if the linter or mocha thrown an error, the commit or the push will be failed.
Proud of our code maintenable, solid and sexy, we commit, we push… and our reviewer see the 54 commits for 70 files edited and fall from his chair! Effectively, this issue was really to bigger and we should have a issue by module installed… Furthermore, our branchs are unreadable because of a wrong use of git! (never forget to checkout master before create a new branch…). Do little issues allow to the reviewer to validate more quickly and more easely the PR. In this case, we should have see before our manipulation’s error and many hours to merge rebase.
This first week in umanlife was really interesting. Starting a professional project is really different to start a personal project. It needs to use new concepts like coverage and git hooks. It needs to optimize the time with tools like gulp and eslint.
Working in groups requires to use correctly github.
Fortunately, in Umanlife, we have a great team of dev. And anybody is happy to help each other, to explain the good process.