We continue to struggle with the frontend routine / 2GIS Blog

Six months have passed since the latest news about TARS on Habr .

Let me remind you that TARS is a gulp-based html-layout compiler to help any frontend developer (or even the whole team) for creating projects of any complexity. Over the past six months, 88 issue was closed, 7 versions were released, CLI appeared , it turned out that relations did not work out with yeoman, so a new version appeared. TARS moved to his new home on github, got a team of 4 developers + a small army of fans. By the way, thank you so much for instant feedback after the releases and not only. TARS has been introduced in several web studios in Russia and abroad. The collector taught the component approach to more than a dozen developers, attracted those who were afraid of the entire layout routine into the ranks of the frontend. In general, a lot of new things appeared, and I would like to talk about this.

A small outline of the article:

• briefly recall what TARS is;
• talk about the latest;
• let's talk about what is most often misunderstood. How to use TARS to get the most out of it;
• what awaits the project ahead;
• words of gratitude.

What is TARS?

So, for starters, we’ll answer the question of what TARS is, in more detail. A small copy-paste from the last article: “TARS is a set of gulp tasks for automating most frontend tasks + the ability to easily add new ones if there is something missing. TARS can be called a gulp framework. Suitable for both individual developers and large teams. With it, it is easy to develop projects of any complexity: from landing to a huge portal. You don’t even need to know how gulp works, since everything that was made out in the options, all the code and use cases are documented.

More information can be obtained from a previous article and recordings of a performance with FrontTalks.

What's new?

First of all, I’ll say: use the news with any version of TARS, since within one major version 100% compatibility of your project is guaranteed. Guide for updating the project documentation .

The main novelty is the CLI for TARS. What the TARS project represented before the CLI: project files + all node_modules for TARS. And so in every project. Each size increased to 250 MB, which was extremely inconvenient if there were more than 5 projects. When creating a new project on Windows, dependencies were installed for more than 5 minutes.

It was necessary to remember the names of the commands, the name of the keys, there was no verification of the correctness of the keys used, what can be used together and what is not. In general, TARS removed one routine and added a slightly different one. To fix this, we created the TARS-CLI .

TARS-CLI - npm-package (installed globally), which allows you to:

• get the project involved;
• run tasks for assembly (both maidens and release) of the project;
• add a module to the project with a different set of files and folders, you no longer need to do it by hand;
• add pages to the project, both copies of the existing template, and completely empty;
• run any task from gulpfile.js in the current directory at all.

When you run a command with incorrect flags, you will receive an error message. When you initialize the project, you no longer need to edit tars-config.js with your hands, just answer a couple of questions in a very convenient (for the console) interface. At the same time, they saved work with flags if you do not want to choose an operating mode each time or you perform automatic testing. Like TARS, TARS-CLI has good documentation in two languages: Russian and English . Translation of documentation (for both the CLI and the main project) into English is also new. The reason for the transfer - TARS interested developers from the Czech Republic, USA, South America. It is not solid not to have documentation in English.

The general list of the most significant changes:

• added support for Babel;
• the import, sourcemaps directive is supported, despite the fact that styles are concatenated;
• Added support for PostCSS;
• accelerated the assembly process;
• cleared a lot of bugs, conducted a serious refactoring, added a lot of useful little things.

In fact, the list of changes is much larger . New users have had a good influence on the development of TARS. We implemented new ideas, accepted pull requests, and one of the developers through TARS got a job in 2GIS.

It's also worth mentioning that each release now goes through automated testing on Windows, Linux, and OS X, which makes it possible to produce more reliable code. The status of the assembly is displayed on the badges in the readme of the project.

By the way, the collector has been successfully used to develop applications on Cordova, extensions for browsers, etc.

FAQ

For development, it is desirable to use exactly TARS-CLI. If you practice building the project on the server, then use TARS separately. In this case, there will be no global dependencies. But no one bothers to use TARS-CLI either.

You can use any TARS assembly with TARS-CLI. Fork, add tasks, modify the collector to cover your needs. To activate a project, do:

tars init -s http://url.to.zip.with.tars

Thus, TARS-CLI is an interface to TARS, with which it has become much more convenient. Now let's move on to the most common questions and misunderstandings that we received by mail or in gitter.

Question : is it possible to use TARS without fear that I will remain with a “broken trough”? Will the project be abandoned?
Answer : you can definitely use it without fear. Problems may occur, but they are all solvable. In the worst case scenario, our team will be able to build your project and send it to you by mail. In the near future, it is planned to make an online build service if something went wrong locally. We are definitely not going to throw the project, every week there are new issue + the second version on the nose. Neither we nor you will be bored. Over the past month, TARS-CLI delivered more than a thousand people, according to statistics from npm.

Question : Our team has our own gulp / grunt collector, I would like to use the experience from it in TARS.
Answer : you can transfer the necessary tasks to user-tasks. To use grunt tasks, if you do not want to rewrite to gulp, there is a gulp-grunt packagewhich runs grunt task in gulp. But still we recommend porting the grunt task to gulp. Moreover, all grunt plugins are available in gulp. If you want the project to always keep in touch with these additional tasks, I recommend creating a fork of TARS, adding the necessary changes to it, and informing the project with a link to your fork. At the same time, to simplify updating the fork, all custom tasks should be added to users-tasks, and dependencies for these tasks should be specified in user-package.json. They will be set with every project that is awarded.
In addition, if your tasks will be useful to a large number of developers, we ask you to make a pull request. Description of how to work with us is available here .

Question : what is the best way to build a development process using TARS?
Answer : There is no single answer here. It all depends on the specifics of the development.

Consider several types of projects.

1. Long-playing and unique. In this case, everything is simple. Create modules, pages, store everything in any CVS - in general, this script is the most boring.
2. Many projects with repetitive functionality. In this case, there are several ways to work with TARS.
   
   • Create a library of reused blocks and include it immediately in your own fork of TARS. Thus, when the new project is launched, it will immediately contain all the necessary blocks.
   • Use git or any other CVS. Suppose that the tarred TARS is in git, and each new project is a separate branch.
   • Keep a library of duplicate blocks separately.
   
   The first option is the most convenient. But in this case, you need to monitor the state of the fork and timely take the changes from the original repository.
   
3. Many different projects. Also a very simple scenario in which each project can be a separate repository in git (or another CVS).

The above methods are not a dogma, but just an example of how to get more benefits from TARS.

Question : It seems that the technology stack that you offer is the last century. Everything has already been moved to webpack, and scripts run through npm without any gulp / grunt / broccoli / anything else.
Answer : let's start with the fact that the same gulp has more than twice as many stars on github as webpack or something like that. Calling gulp obsolete is at least incorrect. Each task has its own tools.
If you have a very simple project, you only need to glue the styles and compress js, then you can write everything yourself and run it through npm. And you can not waste time on this and engage in the project itself, and entrust everything else to tools that are just made for these needs. In fact, it is surprising that developers are ready to use the package manager as a task runner. But this is already tasteful.
Back to the webpack question. Nothing prevents using gulp with webpack. Actually, there are plans to implement either webpack or browserify.

Question : nothing is clear, some modules, pages, a bunch of errors, nothing is being put, what is happening at all?
Answer : read the documentation in Russian or English. Or write to [email protected] or in our chat room in gitter . All quickly fix. Feedback will not be superfluous at all, so if you find any error in the work of the collector, report it

Future plans

Follow up on github for further plans . There you can and influence the project. We are always happy for new ideas.

In the very near future we plan:

• make a promotional site;
• webpack, browserify, something else;
• move to the fourth version of gulp when it is released;
• give the opportunity to build React applications;
• make an online version of the collector;
• start working on the second version of TARS;
• create infrastructure for TARS plugins.

The last two ideas are the most interesting. If everything is not clear with the second version, then you can already talk about plugins. Plugin system - various additions to TARS, which are needed to solve "narrow" tasks. The simplest example is task for typesetting letters. Imagine you just type tars install tars-email, and tasks are loaded into your local TARS for comfortable work with the layout of emails.

In the near future we will teach TARS to talk. True synthetic voice and only on Mac and Linux. Let's try to add character to him, teach sarcasm. Naturally, all this will be optional: if you want silence, just change 1 option in the config.

Credits

In the end, thanks: Lence_l for the painstaking work on the documentation and its translation, owanturist for working on js-tasks, oleks for great ideas and development assistance, to all the guys from gitter for instant feedback, after the release of the next version of the collector, for great ideas and support .

Use, fork, put stars in github and continue to reduce the level of frontend routine with TARS.