We continue to fight the frontend-routine

Half a year has passed since the last news about TARS in Habré .

Let me remind you that TARS is a gulp-based html layout builder to help any frontend developer (or even the whole team) to create projects of any complexity. Over the past six months, the 88th issue was closed, 7 versions were released, the CLI appeared, it turned out that the relationship with yeoman didn’t work out, so a 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 releases and not only. TARS has been implemented in several web studios in Russia and abroad. The collector taught the component approach more than a dozen developers, drew into the ranks of frontend'erov those who were afraid of the whole layout routine. In general, a lot of new things have appeared, and I would like to tell about it.

A small outline of the article:

• briefly recall what TARS is;
• let's talk about updates;
• let's talk about what is often understood wrong. How to use TARS to get the maximum benefit;
• what awaits the project ahead;
• words of gratitude.

What is TARS?

So, to begin with, we will nevertheless answer the question, what is TARS, in more detail. A small copy-paste from the previous article: “TARS is a set of gulp-tasks for automating most of the frontend's tasks + the ability to easily add new ones if something is 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 the landing page to the huge portal. You don’t even need to know how gulp works, since everything that could have been rendered in the options, all the code and use cases are documented.
')
More information can be obtained from the previous article and recording performances with FrontTalks.

What's new?

First of all, I will say: use the new products 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 CLI for TARS. What the project represented on TARS before CLI appeared: project files + all node_modules for TARS. And so in every project. The size of each 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 teams, the names 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, one routine TARS removed and added a little different. To fix this, we created a TARS-CLI .

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

• zainit project;
• run tasks for the assembly (both dev and release) of the project;
• add a module to a project with a different set of files and folders; you no longer need to do it with your hands;
• Add pages to the project, both copies of the existing template and absolutely empty ones;
• run any task in general from gulpfile.js in the current directory.

If you run a command with incorrect flags, you will receive an error message. When initializing a project, it is no longer necessary to edit tars-config.js with your hands; it’s enough to answer a couple of questions in a very convenient (for the console) interface. At the same time, they kept the work with the flags, if you don’t want to choose the mode of operation each time or you perform automatic testing. Like TARS, TARS-CLI has good documentation in two languages: Russian and English . Translation of documentation (both for the CLI and the main project) into English is also a novelty. The reason for the transfer - TARS interested developers from the Czech Republic, USA, South American countries. It is not solid not to have documentation in English.

General list of the most significant changes:

• added Babel support;
• the import directive is supported, sourcemaps, despite the fact that there is a concatenation of styles;
• Added support for PostCSS;
• sped up the build process;
• cleaned a lot of bugs, conducted a serious refactoring, added a lot of useful things.

In fact, the list of changes is much larger . New users have 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 at 2GIS.

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

By the way, the collector is successfully used to develop applications for Cordova, browser extensions, etc.

FAQ

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

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

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. We now turn to the most frequent questions and misunderstandings that we received by mail or in hitter.

Question : Is it possible to use TARS without fear that I will stay at the “trough”? Will the project be abandoned?
Answer : you can definitely use without fear. Problems can occur, but they are all solved. At the very least, our team will be able to knock out a project for you and send it to the post office. The near future is planned to make an online assembly service, if something went locally wrong. We are definitely not going to give up the project, every week there are new issue + second version on the nose. Neither we nor you will be bored. Over the last month, TARS-CLI was delivered to more than a thousand people, according to statistics from npm.

Question : we have a gulp / grunt collector in our team, I would like to use the developments from it in TARS.
Answer : you can transfer necessary tasks to user-tasks. To use grunt-task, if you don’t want to rewrite to gulp, there is a gulp-grunt package that runs grunt-task in gulp. But still, we recommend porting grunt-task to gulp. Moreover, all the grunt plugins are available in gulp. If it is necessary that the project always comes up with these additional tasks, then I recommend creating a TARS fork, adding the necessary changes in it, initit the project, with a link to your fork. At the same time, to simplify the update of 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 placed with every project.
In addition, if your task will be useful to a large number of developers, we kindly ask you to make a pull request. A description of how to work with us is available here .

The question is : how best to build a development process using TARS?
Answer : there is no single answer. 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 reusable blocks and include it immediately in your own fork TARS. Thus, with an online new project, it will immediately have all the necessary blocks.
   • Use git or any other CVS. Let the unmarked TARS is in git, and each new project is a separate branch.
   • Store 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 take changes from the original repository in time.
   
3. Many different projects. It is also a very simple scenario where each project can be a separate repository in git (or another CVS).

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

Question : It seems that the stack of technologies that you offer is the last century. Everything has already been transferred to the webpack, and the scripts through npm are run without any gulp / grunt / broccoli / something else.
Answer : let's start with the fact that the same gulp has more than twice as many stars on a github as a webpack or something like that. Calling gulp obsolete is at least incorrect. For each task has its own tools.
If you have a very simple project, you only need to glue the styles, squeeze the js, then you can write everything yourself and run through npm. And you can not spend time on it and do the actual project, and everything else entrust the 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 a taste.
Let's return to the webpack issue. Nothing prevents you from using gulp with a webpack. Actually, there are plans to introduce either a webpack or browserify.

Question : nothing is clear, some modules, pages, a bunch of errors, nothing is put, what happens at all?
Answer : read the documentation in Russian or English . Or write to tars.builder@gmail.com or to our chat in gitter . Everything is operatively fixed. Feedback is not at all superfluous, so if you find any error in the work of the collector, report it

Future plans

For future plans follow on github . There you can also influence the project. We always welcome new ideas.

In the near future we plan:

• make a promotional site;
• webpack, browserify, something else;
• move to the fourth version of gulp when 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 the second version is not yet clear, then you can already tell about the plugins. The system of plug-ins - various additions to TARS, which are needed to solve "narrow" tasks. The simplest example is task for typesetting letters. Imagine, you simply type tars install tars-email, and your local TARS are loaded with the task for comfortable work with the layout of e-mails.

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

Credits

At the end of gratitude: Lence_l for the painstaking work on the documentation and its translation, owanturist for working on js-tasks, oleks for great ideas and help in development, to all the guys from Hitter for instant feedback, for releasing the next version of the collector, for great ideas and support .

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