Working in a development team is quite different from working alone or working with only one person. Without shared configurations, rules and reasonable workflow, the more people working on the projet, the more likely the project becomes a mass. In contrast, building shared configurations, creating reasonable workflow, and sharing good working practices are like making good investment: the team will earn benefits everyday with the productivity. They also help with guaranteeing the quality of the deliverable and shipping the application more efficiently.
In this article, I will talk about how to better construct and ship web application within a development team:
To begin with, we need to ensure that everyone has the same formatting of the code and the same eslint config if they are working for the same code base. It is painful to try to find the real difference in a pull request if 80% of the difference comes from formatting.
In case of this, there are two places where we can look at:
First of all, we need to integrate linter to the IDE for detecting the problemes automatically. Here is the guide for how to integrate eslint to different kinds of IDE.
If your team have multiple projects to work on and you want to share the same eslint config, it is recommended to build shared configuration in eslint. Here is the famous example from eslint-config-airbnb. We can create and share the configuration as a node module with the name of 'eslint-config-your-linter", then add to your project by 'extends' it in your eslint config.
Little notice: When we extend your customized eslint config, we can write "your-linter" instead of "eslint-config-your-linter" because eslint will remove 'eslint-config' automatically.
IDE has a configuration file for the rules of formatting, and here is an example of the configuration file of vscode. In addition, there are plugins for IDE for formatting the code and we have also the configurations for the plugins. Here is an example from prettier, an extension for formatting the code in vscode. It is recommended to share the config for prettier like the config of eslint and babel.
If we work for multiple projects, it is good practice to create a node module for sharing the configuration for eslint, stylelint, jest config, babel config and webpack file. We can also share images, fonts, css, helper functions and even React components. The node module can be hosted on npm, github, or any cdn. If it is hosted on github private repo, we need to provide ssh key or https token for installing it.
In order to import something from a shared node module, there are different ways to make in different kinds of files.
import x from "my_module/x" // ES6 (React...) const x = require(my_module / x) //ES5 (node script, webpack, jest config ...) ./node_modules/my_module/x // in package.json import "~my_module/x" // in scss
Maybe it is quite strange to talk with writing tests here, but it is indeed important and always been ignored while development.
There are two advantages for writing tests:
Webpack makes front-end development workflow more fluid and professional.
In detail, as I mentioned in another article about webpack. There are three main purposes of webpack:
There are lots of good tutorials, but we can always learn from the best. For example, the webpack config for the famous create-react-app coule be found here.
Here are some special techniques:
We have done a great job locally! How can we ship it better ?
The answer is continuous integration and continuous development, it means that the project will be built, tested, and even deployed after every commit.
During continuous integration, the changes within a commit will be passed to server, built and tested automatically. If there is a problem with the test or with the build, an error will be thrown immediately and stop the process. Here is the workflow of continuous integration:
Continuous delivery goes one step further than continuous integration. After the build and automatic test, the code will be deployed to cdn so that the product owners can make manually tests on the recette environments. Here is the workflow of continuous delivery:
In case of tools, nowadays gitlab and github have native CI/CD tool. There are also plenty of third-party services like Codeship. Docker is always preferred for preparing for linux environment.
It may take time and energy to make right tools and create reasonable process for your development, but it will worth in the end!