More comfort in front-end development with TARS

The next six months have passed since the last news about TARS ( one and two times ), which means it’s time to share the news. As always, I remind you that TARS is a Gulp-based front-end collector that helps the front-end developer or even the whole team create projects of any complexity. We continue confident procession across Russia and not only. TARS is already used in the Netherlands, Japan, China, Ukraine, Poland and other countries. This can be seen both in the number of stars on github, in the number of chat participants in gitter , and in the number of TARS-CLI installations for the last month (more than a thousand, and at a peak more than 3 thousand). We closed almost two hundred issue, released two major updates. Users of the collector actively report, participate in the development. We can say that we have a small community.

Major changes

TARS has become truly, without any reservations, modular. The speed of launch and assembly has increased significantly. The most significant changes include webpack and auto-update of the project (updating the version of the collector, and not reloading in the browser).

Finally, JavaScript can be compiled not only by simple file concatenation. It was even a shame that in 2016 the assembly of scripts in TARS was so backward. Webpack has untied his hands in working with JavaScript. Hot Module Replacement , which is also supported out of the box in TARS, works wonders. And with the injectChanges option for styles in Browser-sync, the development becomes fantastic - the browser does not restart, and on the fly applies changes to CSS and, if possible, in JavaScript. If you go further, you can shift the work with styles and templates on the webpack. Since any task in TARS can now be easily redefined, transferring responsibility for CSS and templating is easy to implement with a webpack. If we talk only about building JavaScript, then the webpack here provides a lot of features that are easier to read in the documentation. In addition, from the second version (it is in beta testing), Tree shaking appeared, which allows you to import into each point of the application only the code that is actually used in the module.
')
With the arrival of the webpack in the project, you can ask why Gulp is needed at all, if everything can be done with the help of webpack and npm scripts? The answer is very simple: everything is much simpler with Gulp.

In fact, there is no question about webpack - in TARS, you can simply disable the tasks that compile templates and build CSS and use the corresponding loaders. So it’s worth rephrasing the question differently: why do we need some kind of abstraction in the form of Gulp, when its functions can be performed by npm scripts?
Many articles have already been written, explaining the power and advantage of npm. I will try to answer the most compelling arguments. I think it is worth clarifying right away that this is the case when we have many tasks, between which there are dependencies in the order of execution.

Let's start with the fact that you have to write your implementation to run tasks sequentially and in parallel. Why, if there is Gulp, who knows how to do it perfectly well? In addition, it is sometimes convenient to work with threads when processing a set of files. Either you have to write this functionality yourself, or just abandon it.

A serious argument in favor of switching to npm-scripts is poor plug-in support for Gulp. We are talking about gulp-plugins, which are a wrapper for various modules such as UglifyJS, PostCSS, etc. Naturally, there may be a small “lag” between, for example, updating UglifyJS and gulp-uglify, but more often than not it is not significant. It often happens that the creator of the Gulp-plugin and the package itself, for which this plugin was written, is one person. It does not exclude the fact that someone can simply abandon their development. In this case, you can either continue development for the author, or use the package directly, without the gulp wrapper. This is how a webpack works in TARS.

Well, and finally: work with tasks is much more pleasant than long foot wrappers in package.json. Of course, for a project in which there are only a few tasks, a footwoman is unlikely to succeed. In the case of TARS, when we are trying to cover as many developer needs as possible with one tool and have complex dependencies between sequential and parallel execution of tasks, using npm scripts does not justify itself, but rather inserts sticks into the wheels.

Gulp is a very easy-to-use thing, tested in various environments, on different platforms. Only 4 API methods are available for you and the ability to create a complex script for parallel and sequential execution of tasks. In the end, you don’t even need to know that Gulp is under the hood, because TARS just works.

If webpack support has long been implemented in many projects (and somewhere the builder is built only on a webpack), then no one provides such a feature as auto-updating of the project. With TARS, you can safely develop your website / service / something else and get all the latest TARS features as a team. In this case, all settings, project files, user tasks and watches will be saved. Yesterday you concatenated JavaScript-files, and today, having updated the project, you were able to use webpack. All update steps are logged plus there is an opportunity to add your own commands, which will be launched when the project is updated.

Next will go not so significant, but no less useful changes.

Useful stuff

ESLint replaced JSCS and JSHint. By the way, recently the main maintainer of the project of the JSCS Marat Doolin reported on the transition of the JSCS team to the project ESLint . So, if you are not using ESLint yet, it's time to start. Checking the code began to take place much faster, it is convenient to work with the config - in general, convenience is from all sides.

The TARS code and TARS-CLI were thoroughly refactored and rewritten on ES6 (with support for the features that are available in version 4 of NodeJS). In general, everything has become cleaner and clearer, we hope that there will be more pull requests in this regard. The main gulpfile now pleases the eye, because it consists of only 30 lines. Since the code was written on ES6, I had to abandon support for NodeJS version below 4. The documentation was updated, corrected many typos, errors, etc.

Added the ability to use SVG-symbols. At the same time, it is possible to choose the option to connect the finished character sprite: insert the sprite code into the body of each page, keep all the characters in a separate file, and specify the path to this file (automatically, of course) or enable you to load the file with symbols yourself.

Modules have been renamed to components. In this case, the name for the folder with components / modules can be configured in the config if the new name is not to your liking. Now it is possible to nest components into components. This feature is also supported by the CLI utility.

There have been many requests for custom components to be built using the CLI. You asked - we did! Now you can describe the component's scheme in the json-file, and you can make as many schemes as you need.

Almost all plug-ins that are used in TARS can be customized as it is convenient for you in one common configuration file.

Implemented the ability to compile styles not by automatic concatenation, but by using entry points into which you can import only what is required in the final assembly. We hope that this will give more freedom in working with styles.

Significantly accelerated rebuilding Jade-templates. Now we cache everything we can and reassemble only what is really necessary at this stage.

And most importantly, you can get all these innovations simply by running the command:

tars update-project 

Your project will be automatically updated to the latest version with all the settings saved.

Future plans

The development of TARS does not stop, there are still a lot of things that I would like to implement:

• finally go to version 4 of Gulp when it comes out of beta testing;
• go to the second version of the webpack when it comes out of beta testing;
• enable the use of [Rollup] (https://github.com/rollup/rollup) as a JavaScript collector;
• create infrastructure for TARS plugins. The system of plug-ins - various additions to TARS, which are needed to solve "narrow" tasks. The simplest example is hacking for writing letters. Imagine, you just type “tars install tars-email” - and your local TARS are loaded with tasks for comfortable work with the layout of emails;
• realize the possibility of using PostCSS without any preprocessors;
• implement support for css-modules;
• finally finish the promo site;
• write more tests on TARS and TARS-CLI.

Now TARS is developing without losing compatibility with previous versions, which is why in the new versions there are entities that it would be nice to get rid of. I would like to break this compatibility so that in the next version there is nothing left. Be sure to implement a mechanism for at least semi-automatic updates from 1.xx to 2.xx

For future plans follow on github . There you can also influence the project. We always welcome new ideas. Write to gitter and email tars.builder@gmail.com In the near future, perhaps, there will be a channel in Slack and / or Telegram.