I am working in some development team. We have unit tests in our programm. There are many tests in it. Each test covers one module. In common, one developer is working only on one or some modules (but not many) per one task. To improve unit tests speed I use focused specs (I use Jasmine and our app is AngularJS app).
The problem: sometimes I forget to remove focused specs. I commit and PR with fit/fdescribe calls in programm. It can cause problems for me and other developers in the future. Obvious example: developer is developing :), he made a mistake, he started tests and only focused specs worked, since he worked on another file - it is a problem - there will be mistake but he wouldn't see it.
Is there any methods to automatically find focused specs in my tests and warn developer about it? Our team is using CI with grunt running on it. Grunt has tasks for jscs and jshint. Maybe it is somehow possible to create own rules to prevent this mistake?
I would setup a git hook and utilise grunt-ddescribe-iit.
For now, let's use grunt-githooks to setup the git hook.
grunt.initConfig({
githooks: {
options: {
'pre-push': 'grunt ddescribe-iit'
}
},
ddescribe-iit: {
files: [
'test/**/*.js',
'app/**/*.spec.js'
]
}
});
That's a very contrived example of how I imagine it would work, I haven't utilised ddescribe-iit myself (though, like you - I should be!) nor have I used grunt-githooks.
Looking through how they're both put together however, my established guess is that this would be a fairly painless process to set up.
Like you, we are also utilising a CI system and it has always been a pain when a build passes, but it only ran a couple of chosen tests. Using a git hook that screams in your face before pushing, kills the problem at the root I reckon (without introducing watchers and additional processes during the development step).
All at the amazing cost of development overhead of 0.
edit: this answer assumes that you are utilising grunt as a task runner. there are equivalents for gulp.
Related
TL;DR; Is it possible to implement package inheritance in Node? Or is there a recommended tool to help with this?
I am working in an enterprise environment containing 60+ (and growing) web apps. We’ve also modularized components such as header/footer/sign-in/etc. so the web apps don’t need to repeat the code, and they can just pull them in as dependencies. We also have library modules to provide things like common logging, modeling, and error handling. We also have one main library that provides a foundation for maintenance like testing, and linting.
What I am trying to do is get access to the dependencies this main library uses in upper level modules.
lib-a
|
—> lib-b
|
—> babel, chai, mocha, etc.
I would like to have lib-a “inherit” babel, chai, mocha, etc. from lib-b rather than having to specifically add the dependencies. That way all my libraries, and eventually web apps will have the same version, and I won’t have to repeat the same dependencies in every package.json. Nor will I need to go through the headache of having N number of teams update the 60-100 apps/libs/whatnot, and having to deal with them complaining about maintenance.
I do understand this goes against the core of npm, but on the level we are using this it’s becoming a maintenance headache. Going more DRY would certainly have it’s benefits at this point.
So to repeat the original question at the top - Is it possible to implement package inheritance in Node? Or are there any recommended tools to help with this?
I have seen the following tools. Has anyone ever used them? or have thoughts on them. Are there others?
https://github.com/FormidableLabs/builder
https://github.com/Cosium/dry-dry
It's a bad idea. You should assume that you don't have control over the dependencies. How else would anybody be able to make changes to the dependencies?
Suppose lib a from your example uses mocha. Since it depends on lib b which also depends on mocha, you could decide to not list mocha in lib a's package.json.
If somebody refactors lib b to not use mocha anymore, lib a will fall all a sudden. That's not good.
We work with equally many projects. We use Greenkeeper, RenovateBot, and some tools that apply changes to all our repos at once. In the long run that's probably a better strategy for you than going against Node's dependency model.
I want to write a node cli application and im wondering how i should structure the application. Im fairly new to node and im a confused with all the design patterns used when building such a application.
I want to be able to call the application from the command line, but also use it as a node module for better testing.
Currently i have one file with lots of functions that get called directly from the cli, but i feel this is rather difficult to maintain.
Is there any good writing on how to do such things? i looked at rimraf but it confused me even more. Thanks for your time
I don't know if there is a "right" way to do it but I can tell you how I have dealt with a problem similar to yours. I wanted to create a CLI and a visual studio code plugin so people would be able to use the functionality both from VSC and from the CLI (for those that don't use VSC), so the approach I took was to put all the logic in its own package and then create two other packages that included the first one, one for CLI and one VSC plugin that required the "logic" package.
In the CLI package you would only have code strictly related to command handling and then the real meat happens in the logic package. In my case the VSC plugin package had very few lines of code, just configuration and the calls to the needed functions.
Then regarding the structure of the code some recommendations:
expose only what is strictly necessary
isolate your code in different files/classes based on common functionality (and go to point 1)
test your code
lint your code
But those are common sense and language independent recommendations.
There's no one "standard" way to structure Node.js apps, however you will notice that many authors follow similar patterns. Instead of having one file containing all code, it should be split out into modules, grouped by function. Have a look at this repo on Github, it has some very good suggestions about Node.js best practice https://github.com/i0natan/nodebestpractices#1-project-structure-practices.
A couple more pointers I would add: Ensure you're logging any errors, consider using something like Winston.js for this purpose. Also have some mechanism in place to restart the service if a critical error occurs, e.g. Forever.js.
Ensure likewise you're unit testing, there are some good test frameworks, Jasmine, Mocha, Cucumber.js.
Since I know now, what "angular compiler" actually means, this would be my next question.
I read here about the positive and negative points of ahead of time compiling. To me, it boils down to this:
Use AOT for deployments
Use JIT for development
The only valid reason (imho) for JIT is, that it runs way faster (which is nice for the development process). Is there any other reason?
AOT has so many HUGE advantages over JIT, that I wonder why JIT is even an option for for a deployment.
Well, There are many difference and some of them are pointed out by you very well. It also dependent what kind of environment you are in and your requirement.
I have been using angular since angular-2.beta.17 when angular cli was not existed and we have to take the help of many build system and run environment to run the project in anywhere.
Systemjs building and running:
In some situation where multiple project and frameworks run together, you can not make a AOT build and bootstrap your code into the SPA and run. In system js environement you have to load the scripts one by one and they bootstrap it.
You must have seen this kind of build and loading script in many online tools like codepen, plunker, etc. I think they all uses systemjs loading
There are many other like commonjs loader, babel build system, webpack build system. But now angular cli is a bullet proof tool with internally use web pack and amber cli to handle everything you want.
Ahead of Time compilation and JIT debugging
As the name suggest AOT do a tree shaking and include everything which is really used in your code and throw away unused codes and compact the code size which can be loaded very fast. But by doing that it looses debugging control and don't give you a nice error message if in case in production you want to see what is wrong.
Same time JIT can point to the line number in typescript file which have the error and make your life super easy to debug while running in dev mode through angular cli.
You can get lot more in angular compiler and there are many tools and games available as well.
one of my favorite is ngrev
I'm trying to get into Grunt, which I am new to, but I do not understand its utility.
I understand that it is a taskrunner. I understand that it can be used to do things like bundle, uglify, jshint, minify, etc etc etc, anything that can be turned into a scripted task.
But I don't see what advantage this gives. Nearly all of these can be run from the command line anyway, which is to say you could just combine them using a simple shell script. It seems to me that setting up grunt + gruntfiles and writing tasks is more work than writing a shell script, rather than less.
What am I missing about this?
Grunt is basically a build / task manager written on top of NodeJS. I would call it the NodeJS stack equivalent of ANT for Java. Here are some common scenarios you would want to use grunt under:
You have a project with javascript files requiring minification, and generally generating a front end build seperately (in case you're using say JAVA for your backend). (grunt-contrib-uglify)
When you save code on your machine during development, you want the browser to reload your page automatically (might seem like a small thing, but believe me this has saved me lots of time). (Live reload)
When a developer saves code on his machine, he wants a comprehensive list of JS errors / general best practice violations to be shown. (grunt-contrib-jshint)
You have a project with SASS/ LESS files which need to be compiled to CSS files on the developers machine during development, For example whenever he saves a SASS file, you want it to be compiled to a CSS file automatically, for inclusion in your page. (grunt-contrib-sass)
You have a team of front end developers who're working on the UI, and a team of backend developers working on the backend, you want the front end devs to use the backend REST API's without having to compile & deploy code everytime on their own machines. In case you were wondering, this isn't possible with a typical web server setup because XHR isn't allowed to be cross-domain by browser. Grunt can setup a proxy for you redirecting XHR requests on your own system within the grunt connect server to another system! (grunt-contrib-proxy, grunt-contrib-connect)
I do not think your shell script can do ALL of these. To summarize, yes, setting up a Gruntfile.js is tedious for someone who has had little exposure to javascript / is new to nodeJS, I went through the same pains as a learner, but Grunt is an amazing piece of software. DO invest the time to setup a proper Gruntfile.js for your front end project, and you'll thank god for making your life a lot easier :)
The Advantage vs shell script:
If you write shell script for every one of these tasks, it is tedious to maintain and then customize for every one of your needs. Gruntfile.js is actually pretty easy. there is a config that you init it with, specifying what tasks you want to perform, the sources and targets for each.
The integration with project seed generators on Yeoman, Gulp is another major factor to consider. Yeoman and Gulp come with Gruntfile.js' with intelligent defaults. For someone who is the sole UI contributor on his team, this is priceless to me!
For someone who is working on frontend technologies, if you have more than one person working with you, its rather easy for them to get to know Grunt, which is already well documented with a lot of answers on SO, than to get to know your shell scripts. This might be a factor in large teams.
The numerous plugins for Grunt extend base functionality. Unless your shell script is VERY popular, and VERY modular, I dont see plugins being built for it. This also extends to inclusion of new front end technologies in your project. Say, if you want to use typescript in your project tomorrow, your shell script will need to incorporate this and account for it with your own effort. With Grunt, its just as simple as "npm install " and adding a config.
Even though I agree with most advantages pointed in Accepted Answer, I still have to consider the disadvantages that are highlighted by Keith Cirkel in Why we should stop using Grunt & Gulp
Thus, some advantages are rebut by Grunt overheads and at least you should consider all this in your final decision of using Grunt, or not.
I've been using grunt task runner in all of the angular projects I was involved in.
Currently, I found a gulp-protractor-qa plugin for gulp that watches all my element selectors in the tests on the fly. It is good at what it does, but now I have to have a separate gulpfile.js config for the another build system (I cannot find an appropriate alternative among grunt plugins).
Is it okay to use both grunt and gulp build systems in a single project? What are the generally accepted actions in this case?
gulp-protractor-qa is just an example. I can imagine this would hit me again when I would need different suitable plugins in both build systems and would have to make a choice: try to sit on two chairs?
Like you said, if you don't have any other alternative with grunt, I think that the need of using both task runners is real until an equivalent solution is found or created.
You should of course take care of the possible overrides and conflicts that comes with each task you add in gulp, and to me, never mix your watchers. Always choose to use them in one or the other runner cause of the infinite loops. Even if in this case with gulp-protractor-qa you are watching files, there is no dependent task which runs and nothing is written so you should be fine.
Also, since the new dependencies will mainly be the dev ones, the performance of your deployed app will be very slightly affected or not, except if you run your tests on each deploy, that may take a little longer to install them.
It looks like something is going wrong with running two build systems in one frontend project. You have an option to run grunt tasks from gulp (https://www.npmjs.org/package/gulp-grunt) or vice versa, gulp tasks from grunt (https://www.npmjs.org/package/grunt-gulp). First way looks more efficient, because gulp is much faster than grunt. Consider moving to gulp entirely; many grunt plugins have "native" gulp counterparts.
If moving to gulp seems like an option, but you don't like the idea of spending all that time to rewrite buil config for new tool, try to use some yeoman-genereators. In particular, I'd recommend use of awesome boom generator (npmjs.org/package/generator-boom). It's the best generator for angular with gulp build from the box on the table today.