Whenever I start a JavaScript-based project, I see myself constantly building the same initial setup. I have decided to build a repository where I keep my initial configuration so it is easier to use it.
If you have any advice/tips on this setup, do not hesitate to share! I am looking forward to improving it!
Editor Config helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles.
From their own website
Basically, if you ever opened a project and your tab has a different number of spaces compared to the project, you'll have to go to the settings and change that. Editor Config allows you to override these settings and adhere to the project guidelines. Remember to use this in conjunction with ESLint. Otherwise, you may lint to 2 spaces while having Editor Config overriding to 4 spaces.
Code linting is a type of static analysis that is frequently used to find problematic patterns or code that doesn’t adhere to certain style guidelines
From their own website
I have chosen Airbnb style guide and override the indent to 4 spaces. I have no particular reason to have chosen this one. I tried it, liked it and stuck to it. I use 4 spaces because I can see better the encapsulation and prevents me to go too deep into the nest. My rule of thumb is to stick to any style guide you like and be consistent.
Using attributes, you can do things like specifying separate merge strategies for individual files or directories in your project, tell Git how to diff non-text files, or have Git filter content before you check it into or out of Git.
From their own website
I use it to be clear what files are binary and which are text. I also use it to be consistent with the end of lines. One of the reasons I particularly enjoy it is that I can create a new file format and decide how I want Git to interpret it. For instance, imagine you create a new image file format and then Git send to remote by replacing characters to LF, in this case, your file would be corrupted.
A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected.
From their own website
I use to ignore local files such as .DS_STORE. I don't want to stage or even commit those files. This can be a burden when a lot of local directories are created in runtime. Luckily, gitignore.io can speed up this process. I have been using it for a while and I recommend it.
The simplest way to test and deploy your projects.
From their own website
Travis CI allows to test the code on pull requests and even pushed branches. You can even use it to add badges to the repository and to deploy to multiple online services (like Heroku). Most of the times I just use it to lint the project.
Most of the times I use the MIT license. It is very permissive and gives a lot of freedom to whom wants to use the project.
This file allows me to manage my dependencies, provide a quick preview of the project and add multiple scripts such as linting. I also like to have a postinstall script.
This file links git hooks to the .git directory.
Like many other Version Control Systems, Git has a way to fire off custom scripts when certain important actions occur. There are two groups of these hooks: client-side and server-side. Client-side hooks are triggered by operations such as committing and merging, while server-side hooks run on network operations such as receiving pushed commits. You can use these hooks for all sorts of reasons.
From their own website
Git hooks allows to run pre-commit.sh before making a commit. The only way for the files to be committed is to pass this check. This helps to ensure that any commit in the repository follows the style guide.