Research: Installing and Managing Brackets Extensions

You may not have noticed, but Brackets has a lot of extensions. These extensions add all kinds of useful capabilities to Brackets (take a look! I bet you’ll find at least one that you’d want). But, I’m sure that many Brackets users aren’t aware of this list of extensions. Even for those who know about the list, it’s inconvenient to install an extension and hard to find out what’s new or keep your extensions up to date.

We want Brackets to stay light and focused on the features you use the most. Every developer has a different workflow and different needs, so we see extensions as being important to Brackets as a whole. During Sprint 21, we’ve done some research to try to put together an easy-to-use and solid extension manager for Brackets. We looked at other extension managers that have come before us, as well as tools already used in the JavaScript world.

Wireframe of one possible presentation of Brackets extensions

Our plan covers features that we plan to ship soon as well as features that are a little farther out. The big areas we covered are:

  • User workflow for viewing and installing extensions
  • Extension package format
  • How dependencies are handled between extensions
  • How the extension manager will communicate with the extension registry
  • What other package/plugin/extension managers have done

It’s all summarized in the main document, with links to the details so you can dig in if there’s any area of interest for you.

We’d love to know what you think. Many people in the Brackets community have experience with these sorts of systems, and we want to avoid pitfalls or implement best practices you have found elsewhere. If you have thoughts on extension management or assistance you can provide, please let us know on the brackets-dev mailing list.

With research, discussion and implementation of extension management started, we will soon begin a deep dive into how Brackets extensions are written to ensure that we’ve got a solid base for extensions to build on for a long time to come.

The Research

8 Responses


  1. Brian says:

    I whole heartily support a built in package manager, as long as there’s still the ability to install packages outside of the manager.

    If you look at this package manager for sublime text, it’s a very good example of what a package manager should be. It’s quick and intuitive and requires little effort to use.

    That’s pretty much the point of a package manager. Sometimes good plugins can be tough to find, especially if they have little support or are new. And sometimes we don’t even realize there might be a plugin for the task we have. A good package manager should make it easy to find all sorts of plugins.

    Ideally the package manager will have some basic but useful sorting options. Sort by language (packages for HTML, packages for PHP, etc), sort by function (packages for version control, packages for CSS preprocessors, etc) and potentially sort by most popular, recently added, highest rated, etc. But judging by the mockup, that’s already the plan!

    And as I mentioned up top, we should still be able to install a package manually. That’s just the kind of freedom that open source software usually delivers.

    I’m seriously looking forward to this project being developed enough that I can use it in my day-to-day tasks.

    PS I didn’t even know about the current packages, thanks.

  2. A package manager is very necessary and it will make a great addition to what is surely becoming a ground breaking editor. I’d like to see it model (not exactly, of course but rather in its own unique way) what Node has done with NPM and specifically the ease of using package.json files for both package module discovery as well as for authoring and dependency management. Also, having a central repo for add ons would also be a smart idea, maybe with symlynks to github for instance. In any case, I intend to read your main document as I’m sure you have already thought about this a lot.

  3. Bryan says:

    I agree with @Brian (good name by the way). When I saw your post on Google+ I opened photoshop and was ready to make a mockup of pretty much what you’ve done already. The only thing I would add is I would recommend building a separate website that you can search along with having the option for free and paid extensions. Even though your project is opensource nothing brings devs on board faster than cash. I wouldn’t mind paying a few dollars for a great ftp client or something similar.

  4. John says:

    I would love one, honestly. Textmate 2 did an ok job with it, and it works. I just wish brackets had support for other languages, like ruby (for sinatra web dev)

  5. Starbeamrainbowlabs says:

    A package manager would be really useful and would make installing extensions much easier.

    The extension manager in notepad ++ has a drop down menu with all the extensions on it – I don’t think that would be a good idea because once you’ve installed a few extensions it quickly becomes difficult to find what you are looking for.

  6. Personally I think that could be so useful for people that approach for the first time brackets and also for update of extensions too because sometimes could happen that people download a release that will be updated in a while and you don’t know that!
    It’s necessary have it!!

  7. Tom Kilpatrick says:

    I would love an Extension Manager like the Package Manager on Sublime Text 2. I think that simplicity is the key, and that just does it for me.

  8. KytoSai says:

    I love brackets. I want have PHP extension >.< !!!!

    Thanks team !

Post a Comment

Your email is never published nor shared. Required fields are marked *

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


+ three = 5