MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Working with MyGet upstream sources

Upstream sources play a key role in a professional approach towards Package Management. MyGet gives you the option to specify one or more upstream sources for a package feed. Even though this feature has been available on MyGet for years now, we feel it upstream sources deserve a place in the spotlight once: they enable various scenarios that are impossible on any other package management service, and above all: they are a huge facilitator for a smooth and automated development workflow (and thus developer happiness :-)).

In this post:

  • Why upstream sources?
  • Supported upstream sources

Why use upstream sources?

In bullet-form:

  • Upstream sources make it very easy to pull in packages from other package sources onto your downstream MyGet feeds.
  • You can also target these upstream sources to push packages upstream from your MyGet feeds.
  • Any configured upstream source on your MyGet feed will be made available to you in MyGet Build Services, without having to commit any secrets such as credentials or API keys in your source repository. If you're using NuGet: no need to create a nuget.config file!

If you are confused about the usage of "upstream" and "downstream" in the context of package sources, we've got a little poetic explanation for you, which may already help you visualize the relationship between package consumers, your MyGet feeds, and your feed's upstream sources.

Consider the direction in which packages are flowing from a given package source to an ocean of consumers.Your package may have dependencies "upstream", to packages on another feed. From the point of view of those dependencies, the depending package is located "downstream". When a user consumes the downstream package, it will also fetch the upstream dependencies.The consumer, however, is only allowed to fetch or query those upstream packages if the feed being queried (downstream) is also configured to proxy (or mirror) the upstream package source.


Supported upstream sources

By default, MyGet feeds have the public, central repositories configured for each package type. This includes:

  • NuGet: https://www.nuget.org/api/v2
  • Bower: https://bower.herokuapp.com
  • npm: http://registry.npmjs.org
  • Maven: https://repo1.maven.org/maven2

To configure an additional upstream source for your MyGet feed, navigate to Feed Settings > Upstream Sources. Then click Add Upstream Source and select the package source type you want to add.

A dialog will prompt your for upstream source information and will also expose a few common presets for you to take advantage of. Did you know we even support Dropbox?!

Upstream Source Credentials

If you have any access privileges to other MyGet feeds, you will see those in the MyGet Feeds presets, so you can easily build a chain of package sources to facilitate a package promotion flow.

If you select a private MyGet feed you have access to as an upstream source, there's no need to provide credentials to be able to restore packages from it on MyGet Build Services. MyGet will impersonate your user account when authenticating against that upstream source.

For any non-MyGet upstream source that requires authentication to pull packages, you'll have to provide username and password to be used during Basic Authentication.

Warning! Be very careful with password managers and browser add-ons providing auto-completion of credentials!
We recommend disabling these credential managers on the MyGet web site to avoid issues when editing upstream sources. Oftentimes, these tools auto-complete the credentials fields with out-dated credentials (even when editing different settings in the dialog). 
When running into package restore failures on MyGet Build Services, or when noticing that upstream packages are no longer available downstream, this is the most common source of the issue.

In the opposite direction, in order to push packages from your downstream MyGet feed to the upstream source, you may need to configure a (scoped) API key or access token.

Package Source Filtering

Applies to: NuGet (v2 only!)

When the upstream source is a v2 NuGet feed, you may configure additional OData filtering. Filtering is based on the OData v3 Filtering System. Valid filters are similar to Id eq 'jQuery' or IsLatestVersion eq true and Id ne 'Foo'.

Warning! This capability may go away at some point in favor of newer NuGet v3 APIs.
We currently still keep the feature around for some scenarios that are not yet fully supported on NuGet v3.

Adding a package from an upstream source

You can easily add packages to your MyGet feed originating from an upstream source, such as nuget.org, nmpjs.org, etc. This is using the feed's configured upstream sources under the hood. If you want to add a package from another feed onto your MyGet feed, the other feed needs to be configured as an upstream source to that feed.

Adding a package from an upstream source can happen in three ways: manually, by reference (proxying), or by value (mirroring).

  • Manually: you can add packages from an upstream source to your feed manually by using the Add Package button you will find under your feed's Packages page.

Select From Feed in the dialog that prompts.

  • Proxying: the package metadata is copied to the MyGet feed, the package itself remains hosted on the upstream source. When querying the package, we call the upstream source to fetch the package.
  • Mirroring: the package metadata and the package itself are copied onto the MyGet feed. When querying the package, we server the package directly and don't use the upstream source. Mirroring of a package version happens upon the first request for that given package version.

Configuring upstream sources on your MyGet feed unlocks quite a few integration scenarios and automation opportunities!

Proxy packages from an upstream source

You can configure an upstream source to proxy upstream packages through your MyGet feed to your feed consumers. Proxying makes it easy to have a single MyGet feed aggregate packages from multiple sources. Package consumers need only to configure a single MyGet feed, and all packages available on upstream, proxied package sources will become available to them.

Benefits:

  • upstream packages do not count against your MyGet storage quota
  • authentication against upstream, private MyGet sources happens automatically (see Upstream Source Credentials)
  • especially for NuGet: no longer subject to chatty clients reaching out to all configured feeds during dependency resolution (MyGet can be smarter server-side)

Drawbacks:

  • every package request will incur additional latency as opposed to storing the package onto the MyGet feed

Warning! Avoid configuring multiple package source proxies on a single feed, or in a chain of feeds, as this will magnify the disadvantages, and result in very slow feed response times.

The following diagram illustrates the effects of upstream source proxying.

To enable upstream source proxying, you must tick the check-mark next to Make all upstream packages available in clients.

Mirror packages from an upstream source

You can configure an upstream source to mirror upstream packages onto your MyGet feed. This configuration is similar to package proxying, but takes it one step further.

Whenever someone requests a particular package from your MyGet feed for the first time, MyGet will query the upstream source and copy the package onto the MyGet feed.

Benefits:

  • No additional latency (except for the first hit that triggers the package mirroring)
  • Protected against upstream source availability issues
  • Protected against upstream package removal
  • Authentication against upstream, private MyGet feeds happens automatically (see Upstream Source Credentials)
  • Faster builds!

Drawbacks:

  • Mirrored packages count towards your MyGet storage quota (a classic storage versus speed trade-off, you can always upgrade your subscription or request a quote!)

The following diagram illustrates the effects of upstream source mirroring.

To enable upstream source mirroring, you must tick the check-mark next to Automatically add downloaded upstream packages to the current feed (mirror).

Optionally, you can also tick the third check-mark to indicate that any package found upstream is to be considered a package dependency (and should not be consumed directly). This will hide those packages from search results, whilst still allowing you to restore them.

Once upstream source mirroring is enabled, we can consume our MyGet feed from Visual Studio which will also list upstream packages. For example, the example acmecompany feed only lists one package:

One package on our feed

When searching in Visual Studio, we do see packages that originate from upstream sources:

Visual Studio showing upstream packages

After installing this package, our feed now automatically contains a copy of the jQuery package:

Mirror upstream pckages

From now on, the package is available from our MyGet feed directly, without having to explicitly add it manually from the upstream source.

Using a MyGet feed as a staging area (before pushing upstream)

Many development teams are using some kind of package promotion workflow: pushing a package from one feed to another based on quality gates, target audience, or any other criteria. This is very typical scenario for which upstream sources are essential.

Of course, all of this can happen in an automated fashion using package manager client. However, as promoting a package typically involves some kind of human intervention (e.g. release manager approval), we've also made it a first-class feature in the MyGet web site.

Simply pick the package version you want to promote from the package details page, and hit the Push button to initiate the package promotion flow.

A dialog will provide you with additional options. MyGet is also smart enough to detect any package dependencies you might want to push along in one go as part of this package promotion flow.

At this point, you can still make a few metadata changes before pushing upstream. This dialog allows you to:

  • modify or remove the prerelease label of the upstream package version. This allows you to e.g. drop the prerelease label to release a package without rebuilding/repackaging.
  • add release notes to be included in the package metadata. MyGet will even support release notes written in markdown and render them properly on the web site!
  • modify or remove the SemVer2 build metadata part of the upstream package version
  • exclude any detected dependencies or satellite packages from the push action
  • apply source labeling if the package was built using MyGet Build Services. When enabled, MyGet will find the build from which the package originated and will add a label to the source control revision it was built from.

To edit a package's metadata, simply click the Edit button next to it and make the modifications. To apply a given modification to all packages in the dialog, hit the rain drop button next to the editable field.

Using upstream sources on MyGet Build Services

Applies to: NuGet, npm

Upstream sources for a feed are also available during build. This can be useful in the following scenarios:

  • An additional upstream source is needed during build. MyGet will make the upstream source available during build if it has been added to the feed's upstream sources.
  • If you have a private feed requiring authentication but do not wish to add credentials to source control, credentials can be added to the feed's upstream source. These credentials will be available during build and allow you to consume a protected feed with ease.

Applies to: NuGet

  • The API key for an upstream source is also made available during the build process. This means during a build, you can call into nuget.exe push and push packages to configured upstream sources.
  • If you want to make use of nuget.exe push in a build script without having to specify the -Source parameter. This requires a default upstream source to be defined.

Applies to: npm
We strongly suggest to proxy registry.npmjs.org to be able to run `npm install` during build, as npm will default to the MyGet feed as the default registry.

Setting default upstream sources to be used on MyGet Build Services

Applies to: NuGet

The NuGet.config file on our build agents is configured using NuGet's defaults, enriched with all NuGet upstream sources configured for your MyGet feed. Based on these defaults, the following conventions are active:

  • The default upstream source is set to (Aggregate Source), meaning all feeds will be queried for packages in the order defined in the feed's upstream sources.
  • The default push source (when using nuget push without the -Source parameter) is NuGet.org.

Both of these conventions can be overridden by editing the build source configuration.

Auto updating packages

MyGet feeds can automatically fetch package updates made available through the upstream sources.

When adding or editing a upstream source, we can enable this behaviour per package source, as well as an interval when MyGet should check for updates.

Package Source Options

The following options are available:

  • E-mail me when package updates are available: Sends an e-mail to the specified recipient(s) when package updates are available on the upstream source.
  • Include prerelease versions: By default, MyGet will only consider stable packages. When enabled, we will also check pre-release packages from the upstream source.
  • Automatically update packages to their latest versions: Enables the behavior of automatically updating packages from the upstream source.
  • Update interval: Depending on your subscription plan, we can specify how often MyGet should check for updates (up to every 30 minutes on a Professional subscription)

As you can see, MyGet's support for upstream package sources unlocks a wide range of package management scenarios that may help you streamline your development flow and package governance even more. If you haven't tried the above scenarios yet, do give them a try and experience how it may make your life easier.

Oh, and we do support pushing your private symbols packages upstream along with your NuGet packages, too!

Happy Packaging!

PS: Please take 10 seconds of your precious time to tell us how we're doing

MyGet's NuGet and NPM news from the community (April 2017)

Another month, another episode of MyGet's NuGet and NPM news from the community! We'll look at some interesting blog posts and articles found on the Internet, curated by our MyGet founders Xavier and Maarten. Follow @MyGetTeam on Twitter for more!

Note that this will be the last episode of our monthly news for now. Let us know if you'd like to see this series continue!

NuGet news

The NuGet team is considering improving package identity and trust by allowing to verify accounts and reserve package prefixes. For example, System.* could be reserved for the .NET Foundation so consumers always know the package comes from a thrustworthy source. Good read, good thoughts!

Naeem Khedarun built a tool that scans of outdated packages. NuGetXray, as the tool is called, helps identify outdated packages and can visualize this in a nice report (which can be included in a TeamCity build).

More tools! Maarten blogged about extending .NET CLI with custom tools, with an example tool dotnet init that initializes your NuGet package metadata.

MORE TOOLS! Alistair Chapman is introducing the Cake Build Systems Module which gives CI superpowers. For example on MyGet Build Services it will use service messages to add additional tracing to the build log. On TeamCity, the currently running build task is displayed. And more - give it a go!

NPM news

A GitHub PR was opened, discussing npm@5 and what will be included. Work in progress!

Axel Rauschmayer blogged about setting up multiplatform npm packages. In an example, he describes creating a package that targets ES5+, ES6 and webpack at the same time. 

Happy packaging!

Consuming packages from MyGet with Yarn

A while back, Facebook released Yarn – an open-source alternative for Node’s npm package manager. It’s a new client for working with npm packages, with a focus on performance and reliability. There are quite some blog posts out there benchmarking the npm and Yarn clients, but generally an install is somewhere between 9% and 50% faster with Yarn. Let’s see how we can use Yarn with a feed on MyGet!

Consuming packages

Assuming we have already created a feed on MyGet that contains a few packages, let’s first setup Yarn to use that feed as its registry. This can be done using the yarn config command:

yarn config set strict-ssl false
yarn config set registry "https://www.myget.org/F/acme-corp/npm/"

We can also keep the default registry and only configure Yarn for our own scope, so that only our own packages are downloaded from MyGet. No problem, let's set the @acme scope's registry to our MyGet feed:

yarn config set @acme:registry "https://www.myget.org/F/acme-corp/npm/"

The settings are stored in our user profile folder in the .yarnrc file. Just like with npm, the .yarnrc file (and even .npmrc) can be copied into our current project's folder so that settings only apply for that project and not for all comands we execute with Yarn.

Once we have configured our MyGet feed as the registry, we can install packages using Yarn quite easily using the yarn add <packagename> command (which will add the package to our package.json as well). If a package.json already lists dependencies, we can run yarn install as well to fetch all dependencies.

yarn add bootstrap@3.3.7
Do note that for private feeds, the pre-authenticated feed URL has to be used. Yarn does not support private packages out of the box, and a pre-authenticated feed URL is a secure workaround.

Publishing packages

Unfortunately, publishing is not a smooth ride yet. The yarn publish command is able to prompt for credentials succesfully (username, e-mail and password), but after that it seems to hang. Feel free to try it out and post your findings on this GitHub issue.

No problem though: we can still use our good friend npm to handle package publishing.

Happy packaging!

MyGet's NuGet and NPM news from the community (March 2017)

Here's a fresh episode of MyGet's NuGet and NPM news from the community! Like each month, we'll look at some interesting blog posts and articles found on the Internet, curated by our MyGet founders Xavier and Maarten. Follow @MyGetTeam on Twitter for more!

NuGet news

Let's start with the big one: Visual Studio 2017 has been released. A new IDE with a revamped project system (bye project.json), .NET Core tooling and more. Oh, and a fresh NuGet.exe 4.0.

Sean Feldman shares a great blog post about leveraging MyGet web hooks and Azure Functions for sending out notifications.

In VSIX Continuous Delivery using Cake, AppVeyor and MyGet (do make sure to read the entire series), Alistair Chapman covers setting up a CI/CD pipeline using best-of-breed tools.

Steve Desmond released a new tool called LibYear. It is an addon to dotnet.exe  and scans a project for outdated package references. It also features an update  command to update all referenced dependencies in one go.

NuGet Package Explorer is now a Windows Store application.

Just like ReSharper has been doing since forever, Visual Studio 2017 now suggests installing NuGet packages for missing types.

The .NET Core folks started an announcement repository to which you can subscribe to be notified of announcements and changes in .NET Core.

Matt Warren wrote a post with pointers to the .NET Core internals source code. Great list of resources if you want to dive deep into the new .NET.

Ivan Gavryliuk posted NuGet Versioning Hell. Not a rant, but a post on the importance of proper versioning.

NPM news

In the 4.3 branch, NPM released v4.3.3. A fresh NPM version v4.4.1 has landed! Nothing special though, just making sure all NodeJS versions are supported. There is also v4.4.2, bringing along a number of bugfixes. And v4.4.3. And v4.4.4. Or maybe just install the latest v4.5.0.

NPM has an RFC open related to file type dependency specifiers. It makes depending on files inside of our package.json 's dependencies easier. It can point to a package on disk, either compressed or extracted.

Nihar Sawant wrote a post on developing an interactive command line application using Node.He uses the commander  package to build a sample application, which is pretty nifty and handles the async and promises nature of Node in an easy to read manner.

Happy packaging!

MyGet's NuGet and NPM news from the community (February 2017)

Here we are again with a new episode of MyGet's NuGet and NPM news from the community! We will look at some interesting blog posts and articles found on the Internet, curated by our MyGet founders Xavier and Maarten. Follow @MyGetTeam on Twitter for more!

NuGet news

The .NET team announced .NET Core, .NET Native and NuGet Updates in VS 2017 RC. Quite a few changes, most notably the improvements in NuGet to use the new .csproj  format and package references therein. And early in February, NuGet 4.0 RC was released as well.

More news from Redmond: NuGet.org now also supports scoped API keys, just like we do. Where on MyGet scope is per feed, NuGet came up with a per-package model. Do check it out!

Will this be the new way of distributing project templates? As NuGet packages? Muhammad Rehan Saeed found a new element that can be used in a .nuspec  and demonstrates Custom Project Templates Using dotnet new.

Andrey Akinshin, a developer on JetBrains' Rider cross-platform .NET IDE wrote an in-depth article on how they are making the Rider NuGet client fast.

Puneet Ghanshani describes a way of creating an inventory of packages a solution uses by working with the NuGet.Core  package. Would be great to see something like this as a Visual Studio extension!

Scott Addie wrote a great article, Migration to ASP.NET Core, where he walks through the various considerations and strategies of migrating a .NET codebase to .NET Core. The article covers the various frameworks, targets, the portability analyzer, and more!

Just started looking at thedotnet command line tool? Steve Smith explains how to add a Nuget Package Using dotnet add.

Managing the life cycle of PowerShell module assets in your Azure Automation accounts can be challenging. Not anymore! Tao Yang explains how you can leverage MyGet to its full extent to make this tedious task a breeze and take full control of your very own PowerShell Gallery, on MyGet.

NPM news

A fresh npm@4.2.0 landed, featuring improved search - faster and more relevant. Debug logs are now saved in the _cache  folder, making it easier to clean them up.

Node.js itself also dropped a new version - v7.5.0. Ehm no, v7.6.0. Noteworthy changes are an update of openssl (1.0.2k), the ability to use system CA's (yes!) and a number of bugfixes.

NPM Vet is a new tool that allows us to to quickly visualise the difference between versions defined in our package.json  and versions installed in the node_modules  folder. In other words: it helps us check for dependency mismatches.

Happy packaging!

MyGet's NuGet and NPM news from the community (January 2017)

Happy 2017! We hope you had some good holidays and are now enjoying the world of NuGet and NPM again. In this episode of MyGet's NuGet and NPM news from the community, we will look at some interesting blog posts and articles found on the Internet, curated by our MyGet founders Xavier and Maarten. Follow @MyGetTeam on Twitter for more!

NuGet news

NuGet news, curated by MyGetThe NuGet team did another update of their documentation. They have now merged with docs.microsoft.com. Makes sense, with NuGet being such a big part of .NET development.

Support for Windows XP in NuGet is ending on April 8, 2017.

In NuGet, Dependency Management & a single point of package truth, Bobby Johnson published an interesting technique of consolidating all packages folders into one location, making NuGet consume less disk space and avoiding assembly reference conflicts where possible.

Oren Novotny is Multi-targeting the world: a single project to rule them all. His post talks about how you can now use a single project to build platform-specific libraries for all project types with Visual Studio 2017.

Jereme Evans walks us through How to create a NuGet package, set up CI, and other fancy things. The post describes how to create a project with source code on GitHub, using continuous integration on MyGet, publishing to NuGet.org.

Dropcraft is a new NuGet-based app deployment and composition framework. In short, it allows running a simple command, download and extract a NuGet package. The downloaded package can be an app, or a plugin to an app, and composed at runtime.

Steve Smith shares how to re-install packages - useful to help VS in fixing any NuGet references that may be broken.

The new .NET Core tools will be based on Visual Studio project files, so time to change back from project.json to *.csproj. Nate McMaster blogs on how to migrate project.json to csproj and provides snippets on how to do things like multi-targetting, setting metadata, ...

NPM news

NPM news, curated by MyGetNode v6.9.3 (LTS) was released, a well as a brand new v7.4.0.

And a fresh npm@4.1.2 landed as well, with package.json symlink support, updated dependencies, and some additional test coverage.

Brett Nelson continues his blog post series on NPM scripts. In Getting Started with NPM Scripts - Delete Things!, he demonstrates adding custom npm commands (scripts) to perform cleanup steps which many people would use Grunt/Gulp/... for. The scripts approach seems much cleaner and straightforward!

In A way to manage nodejs and npm on windows, Dominique St-Amand explains how to update npm on Windows to the latest version in an easy way. Much better than the horror it is to run npm update -g npm!

Happy packaging!

Configure which feed a token can push packages to - introducing feed-scoped access tokens

Many development teams are making use of a continuous integration server like TeamCity, Jenkins or VSTS to build their projects and push generated NuGet, npm, Bower and VSIX packages to their MyGet feed. When having multiple feeds, it is a good practice to limit the feeds this access token/API key can push packages to, ensuring the surface area of the specific access token is limited to just the feeds the access token requires access to.

In short, scoped access tokens:

  • Are a good security best-practice: use minimum required permissions for a specific operation
  • Avoid services/users accidentally pushing packages by using read-only tokens where possible
  • Allow pushing packages without the ability to get access to other packages on the feed (write-only)

New access tokens and existing access tokens can be scoped in terms of what they can do. We now let you to create read-only or write-only access tokens, optionally limiting write access to just one specific feed.

Create new access token scoped to a given feed

Next to scopes, the access token expiration date and time can also be specified, making it possible to create a time-limited access token that has to be recreated to continue having access to the feed.

Happy packaging!

MyGet's NuGet and NPM news from the community (December 2016)

We've just passed Christmas (Merry Christmas!) and are heading for the new year... Not a lot of people are working, yet we have our fifth installment of MyGet's NuGet and NPM news from the community. Let's look at some interesting blog posts and articles found on the Internet, curated by our MyGet founders Xavier and Maarten. Follow @MyGetTeam on Twitter for more!

NuGet news

NuGet news, curated by MyGetNever hurts to do a little self-promotion. We joined the On .NET podcast to have a chat about MyGet and NuGet in general.

More on .NET Standard by Jonathan Mezach - Sharing code across .NET platforms with .NET Standard. Jonathan provides some good insight in the why and how of the .NET Standard.

Not a bad thing: in the Multiple Versions of .NET Core Runtimes and SDK Tools SxS Survival Guide, Nicolò Carandini expands on the .NET Core runtimes and differences between Long Time Support and bleeding edge versions and how to run them side by side.

Fernando Arias Marques blogged about Dynamically adding a MyGet feed to your VSTS build process, introducing a nice, dynamic and secure way of consuming MyGet feeds and pushing packages to MyGet from VSTS.

NPM news

NPM news, curated by MyGetA fresh npm release! 4.0.5 has been published, mainly bringing bugfixes and dependency updates. There's also a prerelease of 4.1.0, which includes the new npm doctor command which help in diagnosing common issues.

Meanwhile, the npm folks are reaching out for feedback on a bunch of RFC's for npm@5. There are proposals to make npm faster, improve shrinkwrap. Keep an eye on the RFC's an weigh in if there's something you are passionate about!

Have you tried ndm (the Npm Desktop Manager)? It's a nice tool to browse and manage a project's npm packages, much like the git GUI tools available but for npm.

If you have any news to share or have other feedback, let us know using the comments below or reach out on Twitter.

Happy packaging! And happy new year!

MyGet's NuGet and NPM news from the community (November 2016)

It’s November, the holiday season is almost there. In our fourth MyGet's NuGet and NPM news from the community, let's look at some interesting blog posts and articles found on the Internet, curated by our MyGet founders Xavier and Maarten. Follow @MyGetTeam on Twitter for more!

NuGet news

NuGet news, curated by MyGetThe NuGet team just released NuGet 3.5, with mostly performance improvements, features and new target frameworks like netstandard and netcoreapp. The performance improvement during package restore is phenomenal, definitely worth upgrading. And you can now package SemVer 2.0 packages as well (and publish them to MyGet).

They also published a release candidate of 4.0, with support for adding NuGet references in the project file. Which is great as we can now use MSBuild variables in our dependency definitions.

More releases at Microsoft's Connect conference. There's Visual Studio 2017 RC as well as a new .NET Core version (1.1).

Armin Reiter wrote a post titled Powershell package management – NuGet, Chocolatey and Co. He describes what OneGet is and how PowerShell package management (which is now integrated in Windows 10 as well) can be used to install and manage modules and software on our system.

Rick Strahl wrote a post on .NET Standard 2.0 - Making Sense of .NET Again. He covers what .NET Standard 2.0 means to developers and how it fits into the future of .NET and .NET Core.

NPM news

NPM news, curated by MyGetA fresh npm@latest version has landed, 4.0.2 (and a prerelease 4.0.3, adding Node 7 support and a simplified lifecycle for publish events.

Ever wondered what a package manager is made of? Why are lockfiles considered bad practice for libraries but good for apps? Shubheksha Jalan wrote a nice blog post about Javascript Package Managers 101

But what is a dependency? Is it simply code we depend on? Guy Podjarny describes the 5 dimensions of an npm dependency in detail.

What are the bots up to on npm? That was the question Adam Baldwin asked himself after analyzing who else is downloading and running / testing random modules on npm. Interesting finds, for example a package that phones home after being installed.

In 7 npm tricks to knock your wombat socks off, Tierney Coren describes a couple of tips and tricks with the npm command line. For example adding npm completion under bash, or making sure packages you install actually work with the current Node version using "engine-strict".

Elijah Manor and his team started exploring running npm scripts in a git pre-commit hook and run linting before a commit. This technique ensures no invalid JavaScript code can be committed to source control.

If you have any news to share or have other feedback, let us know using the comments below or reach out on Twitter.

Happy packaging!

MyGet's NuGet and NPM news from the community (October 2016)

Here we are again! Our third installment of MyGet's NuGet and NPM news from the community. Each month, we bring you some interesting blog posts and articles found on the Internet, curated by our MyGet founders Xavier and Maarten. Follow @MyGetTeam on Twitter for more!

NuGet news

NuGet news, curated by MyGetWondering what's happening with .NET Core tooling? Microsoft released a blog post with more background information on Visual Studio '15'. Looks like NuGet package references will become part of the project file.

.NET Core 1.1 Preview 1 was just released. It includes support for additional Linux distributions and has many updates, new middlewares and so on.

What's up with all these target frameworks in NuGet and .NET Core? Immo Landwerth sheds some light on NETStandard, discussing how it will solve the code sharing problem for .NET developers across all platforms.

Jeremy Miller wrote a war story converting a complicated codebase to CoreCLR.

Were you using NuGet.Core in your code? Try the new client libraries instead, with support for v3 feeds. Andrei Marukovich wrote a good introduction on the new client libraries that covers some basic operations.

Still learning NuGet? Erik Dietrich wrote a blog post "How To Put Your Favorite Source Code Goodies on NuGet" where he explains the simple process of taking a piece of code, packaging it up and publishing it out there.

On Emin Atac's blog: Inside the NuGet bootstraping process. He looks into PowerShellGet and how it initializes the NuGet PowerShell module provider and brings the required dependencies to our machine.

Filip W.'s proud of Elon Musk planning to go to Mars. Meanwhile, we get to experience this.

NPM news

NPM news, curated by MyGetA fresh version of npm landed, 3.10.9, mostly containing bug fixes in the shrinkwrap and uninstall commands. A pre-release of 4.0.1 also appeared, with some really nice changes in how search works (now streamign results instead of buffering).

Not ony a fresh npm, also a fresh Node.js! The team just baked version 7.0.0 with an updated V8 engine (5.4) which brings performance and reliability fixes.

Want to know how the folks at npm deploy? They just blogged about it. A git push is all it takes, at least on the surface. Quite a few tools and conventions are used under the hood to make that work smoothly.

Hello, Yarn! - Facebook announced a new JavaScript package manager which is fully compatible with NPM and introduces really good installation and resolution performance. We're keeping a close eye on this one!

A great series of blog posts on using Node.js at Scale - npm Best Practices has started. It is a series covering bigger Node.js installations, fordevelopers who already learned the basics of Node from writing clean code to deploying to monitoring.

Follow the leader! The folks at npmjs.com released some boiler plate code for following, replicating or doing other things based on newly uploaded packages. Pretty cool if you want to drink from the firehose!

If you have any news to share or have other feedback, let us know using the comments below or reach out on Twitter.

Happy packaging!