Category Archives: Brackets

Installing the Brackets-ESLint NPM package

07 Jan 2017

If you are interested in an ES6 linter for Brackets there is a plugin called “Brackets-ESLint” that will do the job. However, it cannot be installed like any other Brackets plugin. You must first install a plugin called “Brackets-npm-registry” which functions similarly to the Brackets plugin manager but for Brackets-specific NPM modules.

The Brackets-npm-registry Plugin

Visit the following URL and read through the installation instructions for your platform. Note that on Windows you may have to manually navigate to your AppData directory.

Note that installation may take a few minutes.

The Brackets-eslint Plugin

Once “Brackets-npm-registry” is installed you will notice a new icon in the Brackets plugin bar:


Clicking the plugin reveals the “Brackets-npm-registry” module manager:


Scroll through the list and locate “ESLint” – install the plugin (this may also take some time to complete)

Once installation is complete close the installation window, then close the NPM module manager, and then restart Brackets (F5 on Windows).

Working with ESLint

Upon installing ESLint and restarting Brackets you may see linting issues within the left gutter of opened JS files such as can be seen in the image below:


Place the cursor above the red/yellow icons wihtin the left gutter to reveal a tool-tip explaining the linting issue. Alternatively you can toggle the display of the complete list of issues at the bottom of your editing window (also visible within the above image).

Configuring the Linter

Comments can be added to code to configure the linter. Of particular interest is the ability to instruct the linter to ignore a line of code. For example, this JS comment will remove the line it sits on from linting:

// eslint-disable-line

For example, note the following image and how by virtue of the red “X” icon in the gutter that there is a linting issue for that line:


To tell the linter to ignore the line we add the comment to the end and thus the issue goes away:


For further configuration options, including specifying blocks of code to ignore and configuring the linter via in-code comments see the following guide:

Specifying your Preferred Linter

You may not want to use ES6 linting for your ES5-based projects. In that case you’ll want to update Bracket’s preferences file per the description here to use your preferred linter.

Brackets & Git Integration

14 Mar 2016

If you haven’t already discovered Brackets then IMO you owe it to yourself to download it and check it out. Its an Adobe-backed open source text editor geared towards web development with many exciting features. 2016 will see Brackets being brought into Adobe Dreamweaver as the default code editor (incidentally, Intel’s XDK already uses brackets) along with Edge Reflow’s responsive design features.

Anyway, one of the cool things about Brackets is that various devs have created plugins to integrate Git into Brackets, such as UnGit or Git Branch. The most feature rich of them is a plugin called Brackets Git. In fact, according to the publicly viewable Trello card-wall it is likely to be integrated into Brackets as part of the application.

So then, lets take a look at Brackets Git. I’ve just started working on a project – I ran npm init and git init to help get things started.

Selecting and Creating Branches

How many times have you started working on a project without realizing that you were in the wrong branch? Brackets Git provides a branch drop-down in the file pane showing you your current branch and also facilitates branch switching and creation.


Notice the current branch – I’m currently in the Master branch and I can verify by using the git branch command in Git Bash. As the current branch is always visible It’s easy for me to see the current branch without leaving Brackets.

The branch drop-down also lets me create new branches. By clicking on the Git icon within the file pane, you’ll see a list of available branches (if any) and the option to create a new branch:



Once you enter your new branch name and click “OK” the branch is created and it becomes the current branch (akin to doing git checkout -b branch-name). As before you can check via Git Bash to see if this is what truly happened.

Hereafter, you can select your working branches via the branch drop-down in the file pane.

On a side note, I created a test branch via this method and verified it in Git Bash. Next I deleted the branch using Git Bash and then switched to Brackets to see how the plugin would handle this. It handled it fine with no issues and correctly displayed the changes made via bash.

One thing I observed was that once in a while if I create and change to a new branch via the console $git checkout -b branch-name-here that the branch drop-down didn’t update to indicate both the existence of the new branch and that the new branch had been checked out. To resolve this I selected a different branch within Brackets which caused the branch drop-down to refresh and thus reveal that branch in the list.

NOTE: When creating a new branch you should realize that the new branch will always be based on your current branch!!!! If you want to create a new branch off of master then always select the master branch ***before*** creating your new branch!

Common Git Tasks -Tracking, Adding and Committing Files

Ok, we’ve seen how we can use the branch drop-down to quickly create and move between branches, how about tracking, adding and committing files? Here’s a screen shot of the same project but this time with the Brackets Git UI opened – you access it by clicking the Brackets Git icon in the plugin toolbar.


The Brackets Git interface needs some explanation – the first thing you might notice is that my project has untracked files. Being that this is a brand new project and nothing has been committed I need to do my initial commit. I don’t need to use the console for this as Brackets Git can help complete that task without leaving the editor.

Tracking files (git add)

The equivalent of git add is accomplished simply by checking the check boxes to the left of the “Untracked” text. Before I use Brackets Git to do this lets confirm what I’m seeing in Git bash – that I have two untracked files:


Git Bash shows me something a little different, that I have an untracked package.json and an untracked src/ folder. Within that folder lies the untracked index.html – its a small discrepancy but one that Brackets Git feels isn’t worthy of telling you. Lets use Brackets Git to do the equivalent of issuing a git add command.


As indicated above you can see that the two files are now being tracked. Lets see what Git bash shows us now that we’ve done this within Brackets.


As you can see both the package.json and the src/ directory are now being tracked.

Committing Files (git commit)

As our two files are now being tracked its time to commit them. Clicking the “Commit” button reveals a “Git commit…” panel within Brackets:


Whats cool here is that Brackets Git shows you what was edited when you do a commit, akin to doing a git add -p. The “EXTENDED” button lets you type a longer message. I imagine that if you don’t click the “EXTENDED” button that you are in reality doing a git commit -m “message here” and if you do click “EXTENDED” you are doing a git commit which at the console or Git Bash triggers VI or some other text editor to appear. For now I won’t try the “EXTENDED” option but will do so shortly.

So then, my commit message was “My initial commit”. After entering the message and hitting “”OK” Brackets UI updates and tells me that the working directory is clean:


Lets verify with Git bash:


And lets view the commit:


Ammend the last commit

You may have noticed the option to “Ammend the last commit” in the “Git commit…” dialog. Lets give that a try – I’ve edited the index.html so that its no longer an empty file. Via Brackets Git I’ve added it and have clicked on the “Commit” button. In the screen shot below you can see that I’ve also checked the “Amend last commit” checkbox – and that by doing this the message text field is populated with the previous commit’s message.


To make it obvious that I’m amending the commit I’ll change the commit message to “My initial commit (2)” – and will click the “OK” button.

As before Brackets Git updates and tells me that the working directory is clean. Lets take a look at Git Bash to see what happened.


As expected, the previous commit was amended with the new commit message.

Commit files with the Extended option

Lets try adding an “extended” message. If you don’t already know, the first 50 characters of a commit’s message is used by Git as the commit’s subject line. That’s why you see the character counter next to the message field. By clicking the “EXTENDED” option you’ll see the single-line text field change into a multi-line text area. The first line must still be less than 50 characters but now you have more room to enter relevant text to describe your commit. The section following this one will explain why this matters.

So then, here’s what the commit message field looks like when the “EXTENDED” button is clicked:


Now whats cool about the above screen capture is that you are seeing what was changed in the committed file – it pays to review the edits you are about to commit before you commit them. If there were more than one file you would just scroll through them all via this dialog. Unfortunately, you can’t cherry pick edits…. some things you just have to do in Git bash….

Ok then, lets add a more verbose commit message, taking care to leave the first line below the 50 character limit:


As you can see the first line (our commit subject line) is less than 50 characters – but the counter keeps going as I type. As soon as I exceed 50 characters in total it turned red. I suppose the plugin author may want edit the plugin to only count the first line of text – maybe stop counting at the first line break / carriage return.

Anyway, leaving a blank line in between the first (subject) line and the body of the message is how you distinguish between the two. Ok, time to commit by clicking the “OK” button.

Like the previous commits, the Brackets Git interface updates to let me know that there is nothing to commit and that the directory is clean. Lets look at what happened via Git Bash.


The above screen capture verifies the commit and you can see the second commit and its longer message.

Show history / Show File History

You may have noticed that I was using git log in the previous sections to verify that Brackets Git is doing as advertised. Well, you can do the same thing within Brackets Git via the History and File History buttons:


Recall in the previous section that the first line of a commit message is that commit’s subject, and that it must be less than 50 characters? this is where you see the impact of a short commit subject line – click one of the two history buttons – notice what is displayed as the subject of our commits and that the extended text of the most recent commit is not displayed:


Above, circled in red, is our 50 character or less subject line for the commit where we added a separate description using the “EXTENDED” commit option. You can see how neatly it fits in the window. Imagine trying to read something much longer – it wouldn’t fit and would be truncated at the 50 character limit. That’s why commit messages should be short and concise and the extended option should be used if a longer / more detailed description is warranted.

Inspecting Commits

You can read the entire commit message along with viewing the details of the commit by clicking on the commit itself. The commit details will appear within the main editor’s window:


In the above example you can see that I’ve clicked on the most recent commit and that I can see the extended text of that commit. You can also inspect the individual file changes by toggling the arrow next to each file name or by clicking on the “Expand all” button in the upper right corner.

The screen capture below illustrates viewing a commit’s history and file changes:


Pushing to a repo

Alright, its time to see if we can push using Brackets Git. Everything I’ve done up to this point has happened locally. I’ve just logged into my account and created a test repo called… (drum roll)… “test-repo’. I need to now let Brackets Git know about it. Lets start by clicking the “Pick preferred remote” button where the option to “Create new remote…” will appear.


Selecting the “Create new remote…” option will result in a wizard walking you through the steps of adding a new remote.

First enter the name of the remote repository:


Click”OK”, next enter the address of the repository:


Click “OK” again and you will notice that the Push/Pull buttons have become enabled.


Now its time to push our changes – usually you would need to do this via Git bash:

$ git remote add origin
$ git push -u origin master

Brackets Git handles the above via a dialog with some options – click the “Push” button to see that dialog:


For my purposes the default settings are fine. All I need to do is to provide my credentials, so I enter my username and password and click on “OK”. A console of sorts appears briefly followed by this dialog:


To verify the above I visit the repo itself at GitHub. I see exactly what I expect to see – the single Master branch, my 3 commits and the associated commit messages.


Launching Git Bash

Lastly there are some things that can only be done via a console. Brackets Git provides an easy way to launch the console via the “Bash/Terminal Console” button.



All content © 2012-2017.