In fact this is a problem that you wish to have - system composed of small parts is much more maintainable and flexible than a big monolith that popular framework provides to you. But starting with such granular tooling can be hard.
I’d like to give you a quick overview about what popular tools do - and whether you need them or not.
Having this in mind, let’s jump to the list of popular tools and what they do.
Popular tools and libraries commonly used in modern JS & React codebases
There are other transpilers for the newest ECMAScript standard available - like Traceur, es6-transpiler and much more. Babel.js is so far the most adopted solution to the problem of transpiling your code.
Webpack is a module bundler. It takes your development codebase which is modularized and produces an output which combines your modules into files that can be understood by browsers.
Webpack comes with a development server which allows you to host your code in development environment. Such server is also watching your files and rebundles your code every time you make a change.
Module bundlers also maintain a graph of dependencies between files. This characteristic is a reason why other compilation steps like transpilation are usually integrated with such tool. Webpack does such integrations using loaders. You can transpile your code, uglify it, remove dead code from your codebase and so on.
Webpack has many alternatives but for now is a way to go - it’s the most popular tool to perform module bundling in React communities. Other tools which do the same are Browserify, jspm, SystemJS and so on.
Gulp is a build system or a task runner. It works on a higher level than module bundlers. While module bundlers operate on modules and dependency trees, Gulp works on your file structure - and can perform tasks on them. It is a very similar utility to
make in UNIX environments. It is basically a way to run other tools in a sequence.
In Gulp you define tasks that you can run manually. You define on what files those tasks need to be run and what needs to be done about them.
Gulp operates on streams abstraction. The build process is a set of streams - gulp provides a stream of files and pipes this stream with another stream - like
"uglify" stream which takes file stream as an input and produces uglified files as an output. Then you can pipe it to another stream which does the same on the uglified files. And so on.
So basically this tool is all about orchestrating processes to work on a set of files. Such tools can transpile your code, lint it, optimize your assets, uglify it, compile documentation from comments, produce source maps, run tests, deploy your code… they are very generic - and they work on the files. Gulp itself doesn’t know nothing about modules or what your files mean - but it can ask other tools to perform tasks on such files.
Gulp also comes with basic watchers - you can watch a set of files and perform tasks on them when they change.
Gulp is one of the newer build systems available on the market. There are more seasoned tools like Grunt.
Build systems can do a lot of things that module bundlers can do. But they will propably do it in a less optimised way since all they do is working on files - they do not know abstractions that module bundlers know. Also you can run your module bundler inside your build system. So it’s a higher level tool than module bundlers. Take it into consideration while deciding what should be used in your environment.
npm install command and all dependencies will install automatically. In such package you can also include license info, name, keywords, version, description and many other metadata about your code. If you are developing a library,
npm also helps you to publish it later and make it available for all developers that work within the Node.js environment.
So if you want to install another cool library to use, or another loader for Webpack, or the webpack itself -
npm is a tool that handles it for you.
There are no alternatives for
npm I know for so far.
Bower is a package manager for static assets. While
npm allows you to install packages which can be used to build your code, Bower can help you if you want a stand-alone library without building it or requiring it. All it does it downloads a handful of JS files, stylesheets and images - you can import them to your browser straight away and work with them.
When you build your environment Bower can provide you the drop-in static files that you can use. It shines when you don’t want to build your code, but work on the static assets. It’s great for simple sites and prototypes - fetch a library and use it instantly on the browser with all assets needed.
If you are using Rails-based build environment, Rails-Assets is a proxy between your RubyGems and Bower - so you can use Bower packages in your codebase by including it in your
Mocha is a test framework. All it does is running your tests. It also provides an API for setting test cases - so splitting your tests to pieces.
It is capable of running tests in the browser or in the Node.js environment. It can also run tests for your browser code without running the browser at all - using a headless browser like PhantomJS.
You can use whatever test library you like. Mocha does not assume what kind of assertions you do in your tests.
You can configure Mocha to perform tasks before you test your code - like run Webpack first and then test and so on.
One of the most notable alternative to Mocha is Karma. Both do quite similar tasks and are rather loved by community.
ESLint is a linter for ECMAScript 2015 code. While transpilers can tell you that something is syntactically wrong with your code, linters tell you that your code is not following best practices. It is a great help when you want to maintain high code quality. It can also be annoying because it assumes a certain style guide for your code - but it is highly configurable so you can change behaviour or even disable some checks. You can integrate ESLint with your editor - like Sublime Text (using SublimeLinter) or vim (using syntastic), so your code will be checked frequently against the principles of the good ES2015 code.
There are plugins for ESLint that can also check best JSX practices or React practices in general - like eslint-plugin-react.
It is a great tool for maintaining a good quality of code. It can be also used to establish some kind of guideline in the project if you are working in team - so code produced by many people can be checked against best practices. Not to mention it can be integrated to your continous deployment server so bad quality code will be stopped from entering the production environment. Neat!
There is a little outdated alternative called JSLint which does exact the same thing.
While useful, ESLint is highly optional and you do not need to use it if you don’t want to.
As has been said before, stitching those all tools together can be a hard task for beginners. Yeoman is all about simplifying this process. It is a _scaffolding tool. You find a list of features you want to have and find a Yeoman generator that provides those features. After issuing one command you have a pre-configured environment with features you need.
It is also a great tool if you established a project structure and want to reuse it to make other projects. You just need to create a Yeoman generator out of it and then you can bootstrap a project with similar config in a matter of seconds.
Whew, that is a lot of tools! This comes with strengths and weaknesses. The biggest weakness of such small tools approach is that it is hard to learn what to use and how to configure it. The strength is that if you don’t like a tool, you can easily replace it - there are alternatives for most tools I’ve described here.