Semver carets and tilde in npm

If you use npm you have likely seen notation for dependencies in your package.json like ^4.2.7 or ~3.5.3, etc. Those are respectively caret ranges and tilde ranges. They are well documented on the npm website.

And while I have become quite familiar on how to use them, I had an epiphany recently that I thought I would share. This could help newbies navigate these powerful yet odd notation.

The main power of those notations versus their easier-to-understand cousins x, X and * is that you can fix the lowest version. This is usually critical, because when everybody follows semantic versioning, a library is backward compatible, but your code, as the consumer, does not have to be. Actually, it is only forward compatible.

Let’s say you use a library called foo. The authors of foo, at version 1.2 decide to introduce a cool new bar() method in their package. You want to take advantage of bar() in your code.
If you used the x notation in your package.json, like this:

"foo": "1.x",

It would be technically correct for someone either using your package or a dev on your team to install version 1.0 or 1.1 of the foo package. They both satisfy the 1.x semver. However, bar() is only in 1.2 and later.

By using the ^ or ~ notation, you can prevent that by using:

"foo": "~1.2",

This tells npm that it must have at least version 1.2 but after that, any 1.x version will work with your code.

I hope this helps at least one new person to semantic versioning make sense of this powerful notation.

Comments

Post a Comment

Popular posts from this blog

Running Karma in specific TimeZone

Recently, I had to write some tests related to date and time. In order to tests corner cases, in particular when the UTC date was different from the local date, I had to find a way to set the timezone for my tests. There are countless posts and articles out there that explain how you can set a specific time , but I couldn’t find much about how to actually set the timezone . Many articles references how you could use your browser’s profiles to set it up, etc. But all of it seemed too complicated for my taste. In the end, I came across a gitlab-foss commit by Takuya Nogushi . Simply setting the process.env.TZ variable will do the trick. module . exports = function ( config ) { config . set ( { // your karm configuration } ) ; // Fix the timezone process . env . TZ = 'America/New_York' ; } ; I have not tested with other browsers, but this works with Chrome. The possible values for TZ are available on Wikipedia .
Read more

Calling HttpClient async functions from constructors in ASP.NET 4.5

Recently, we have been using async/await a lot in our ASP.NET MVC project. It is very powerful. However, as with most power, comes great responsibility. In multithreading, this adage can be translated to "with great parallelism, don't deadlock" . As it has been documented and explained, in the current ASP.NET stack, when you await during a request, you will get a callback on the originating thread (that's the point of await/async after all). When you make an awaitable call to let's say HttpClient.GetStringAsync() , it will want to come back on that thread also. As well explained by Stephen Cleary in his StackOverflow answer ( here ), this goes south pretty much immediately if you start blocking somewhere in the call stack. This is true if you call a Task<T>.Result . No async in constructors Unfortunately, for good reasons, constructors cannot be async. Therefore, they cannot await on anything. In our case, we needed to retrieve some data from another
Read more