UPDATE: Yarn decided to drop Bower support for now. We recommend to try it anyway as an alternative to npm!

Yesterday’s official release of Yarn adds an interesting new tool to the world of package managers, bridging the gap between Bower and npm, and adding the most requested features to both.

Yarn looks like a great improvement compared to the current Bower client in a number of ways we’ll describe. It could help you to transition to npm if that is something you’ve been looking for recently.

As Yarn already supports multiple package formats and ecosystems, we secretly hope it will empower JavaScript developers to further develop the ES6 modules ecosystem, as compared to CommonJS used by the npm community, and AMD/globals used by Bower’s community. Browsers and node agree.

Yarn advertises itself as a drop-in replacement for both npm and Bower. This means you will be able to continue using your existing bower.json just like before. Yarn installs bower components to bower_components, npm components to node_modules, and supports dependency flattening!

Important note: As it stands right now there still seem to be some issues regarding Bower support. We are however confident that with the help of the community, these issues will be solved quickly as Yarn steps towards 1.0 in upcoming months.

It is important to keep in mind that just like npm, Bower consists of more than just the CLI component and switching between the npm and Bower ecosystem can still be improved in a number of ways.

Take a quick look at some more goodies that Yarn has to offer:

Lockfile

Faithful users of Bower will be very pleased to see that Yarn adds the long awaited Lockfile feature with even stricter reproducability across devices and systems than npm offers at the moment.

Security

Checking each package against checksum before they are installed guarantees a certain degree of integrity, and gives the developer more confidence from a security standpoint.

Speed and offline

Yarn’s cache is a pretty elaborate improvement over what Bower had to offer so far, reducing (cold) install times by a great deal and even more so in a cached scenario. At the same time it allows complete installs even without an internet connection!

Licenses

The ability to list a dependencies’ license type is often required in enterprise environments. Yarn offers an easy way to list the license type for a given dependency.

Welcome!

You can read more about Yarn in Facebook’s post. Together with npm, we thank the Yarn team for developing it (especially Sebastian). We look for fruitful cooperation.

The bower team has been working hard, getting new features in the project and closing bugs for users and developers. As of 2016–04–05, bower is version 1.7.9.

My favorite one is the option to have —save enabled with every download, as described here 1040, usually when I’m adding a bower dependency I’d like it to be saved on the bower.json, very rarely I would download a package with no project.

Backwards compatibility is important, so by default this is disabled, to enable it add the options “save” and/or “save-exact” to your .bowerrc configuration file.

{
  "save": true,
  "save-exact": true,
}

With save-exact, the version will be persisted to your bower.json, like this:

{
  "angular": "^1.5.3",
  "bootstrap": "3.0.0"
}

All the new features added this month are:

1.7.9–2016–04–05

• Show warnings for invalid bower.json fields
• Update bower-json
• Less strict validation on package name (allow spaces, slashes, and [email protected])

1.7.8–2016–04–04

• Don’t ask for git credentials in non-interactive session, fixes #956 #1009
• Prevent swallowing exceptions with programmatic api, fixes #2187
• Update graceful-fs to 4.x in all dependences, fixes nodejs/node#5213
• Resolve pluggable resolvers using cwd and fallback to global modules, fixes #1919
• Upgrade handlebars to 4.0.5, closes #2195
• Replace all % chatacters in defined scripts, instead of only first one, fixes #2174
• Update opn package to fix issues with “bower open” command on Windows
• Update bower-config
• Do not interpolate environment variables in script hooks, fixes bower/config#47
• Update bower-json
• Validate package name more strictly and allow only latin letters, dots, dashes and underscores
• Add support for “save” and “save-exact” in .bowerrc, #2161

The whole list of changes can be found here.

Bower has seen some smaller updates over the past months and while some of those were really challenging to get right, they bring a lot of improvements. Let’s take a look at some of the things that changed and improved.

A small but important update was the change of our default —-save operator, which used to be the tilde (~) and has now been changed to the caret (^). That way Bower will be more inclusive for minor version updates, as you would expect. As usual this was a non-breaking change, so all packages using a tilde for versions still continue to work.

We removed analytics from Bower! This is a pretty big one, as it was a much requested change that could lead to a break of automated uses of Bower, such as Travis CI builds. While you would be asked „May bower anonymously report usage statistics to improve the tool over time? (Y/n)“ upon using Bower for the first time, Bower is now completely silent in that regard. That being said, we’re also looking to replace the statistics we collect with some more meaningful data and already dropped the command-usage overview, as it is not useful to us or our users.

Bower is now distributed with npm3. This was mainly needed due to a bug on Windows, where paths could become too long for the OS to handle. Especially the bundledDependencies gave us a headache in this situation, however npm3 solves this by using a flat structure, resulting in smaller paths.

Paths in the .bowerrc configuration can now be absolute instead of only relative, which makes it easier and is what you might expect.

We also learned that people are requiring files from Bower’s core more or less randomly, which forced us to release version 1.7.6 and 1.7.7 quickly after 1.7.5 so builds didn’t break. In general there is only one correct way to use Bower programmatically and that is require(‘bower’). Relying on any specific file from Bower that is subject to change is never a great idea!

Apart from those changes there were many more bugfixes, small changes and documentation updates throughout the past months. Check the changelog for a more detailed overview. You can get all those updates and bugfixes by updating Bower via npm install -g bower.

We already have some great commits for the upcoming version and are always happy to see new people contributing. Step by in our Discord channel or directly over at GitHub.

A short time ago I saw a tweet by Adam saying that Bower was looking for people who would be interested in volunteering to the Bower project. I looked at the tweet and read it a couple of times asking myself if I was good enough to actually be a volunteer to a large project. So I decided I would go ahead and sign up and see what happened, most of me knowing that I would never hear back from a large project. A few days later I received an invite to participate in the repository on GitHub. Uh oh! I actually received the response, now what?

The first couple of days I looked around the code base getting myself familiar with the structure and reading the issues and pull requests. I was not yet comfortable taking on an issue that dealt with making changed to the code base so I decided I would take on a role of handling issues and the wiki. Looking into issues was something that I found myself enjoying because I did not want to get right into fixing bugs, working on features, etc. Instead I was going to gradually get myself comfortable with the Bower community by lending a hand with support on any issues that were outstanding or coming in. After a few dealings with issues, I started to get an understanding of Bower leading me to want to make small changes to the documentation in the wiki. This continued on to the point where I felt confident enough to start to work closer and closer with issue handling and wiki page creation. Each time that the wiki was being updated I felt that we were getting better and better documentation which would lead to a better understanding for those who use Bower in their projects.

It is now a little over a month now - I think - that I have been taking part in the Bower project being a volunteer. I have yet to touch the code base … wait … I did try to make one change but it was one that was not needed. Anyways, I have continued to thoroughly enjoy working issues and documentation for the team. Taking on this role has led me to believe that everyone can take part in any open source project in some way or another. Just as any sports team needs players at different positions, an open source project needs people that contribute in different positions.

If you are like me, one who is not yet confident enough to want to dig into code just yet, there is a role for you. Handling issues, wiki updates, documentation, and more is very important for an open source project, and frankly very much needed. I have learned during this time that I do want to get to a point where I start to get into making a contribution to the code base, but until then I am getting more and more confident by handling other facets of the project which can be just as important.

All who are involved in the Bower project have been very welcoming to me from day 1 and have shown me the rights and the wrongs along the way. If you are like me wanting to get involved in an open source project but are not yet sure if you can handle features or bug fixes, start slowly just as I have done by taking on another role that gets your foot in the door and your confidence level up. It is very rewarding no matter what the role is because all of the roles are important in an open source project. This is what I have learned in the first month of volunteering with the Bower project.

Over the past month, Bower has seen 88 commits, 75 closed issues, 34 wiki edits and 2 releases from 27 contributors spread across 15 timezones. Amazing.

But here’s the really impressive part: Nearly all those contributors had never touched Bower’s codebase until just a few weeks ago when Adam and Dave asked for help. Developers eagerly responded and immediately began triaging issues, writing documentation and fixing bugs. Not only is Bower now more stable and feature-rich, it now has a community supporting it.

As with many open source projects, we’re fortunate to be standing on the shoulders of giants. Bower was handcrafted by some incredibly talented developers. As the project moves forward, it’s exciting to know the number of contributors will continue to grow.

Today we’re releasing v1.7.0 which includes fixes and enhancements that have been on Bower’s radar for years.

Want to get involved? Start by filling out this form.

Then check out the contributing guide and join us on Discord. Two great ways to introduce yourself to the codebase, are to review a pull request or write some tests. Our code coverage isn’t perfect, but it can improve with your help. Want to support Bower but don’t have a lot of time? Help us pay for development and hosting.

Bower offers a clean, unopinionated solution to front-end package management and thanks to people like you it’s only going to get better.