MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

MyGet's NuGet and NPM news from the community

Many are returning from summer vacation, others have been enjoying the tranquility of summer holiday. Whichever side you’re on, we at MyGet have been watching the NuGet and NPM community news in the past few weeks. In this post, we bring you some interesting blog posts and articles, curated by our MyGet founders Xavier and Maarten. Follow @MyGetTeam on Twitter for more!

NuGet news

NuGet news, curated by MyGetOn the NuGet blog, the NuGet client 3.5 RC has been announced, with support for new target frameworks and lots of performance improvements. Additionally, the NuGet team started working on better documentation, now available as a preview on http://docspreview.nuget.org.

More from the NuGet team: they made some changes to the expiring API keys policy. At MyGet we’ve always made this opt-in, and the NuGet.org gallery will now do the same.

New to NuGet? Rohit Chopra has you covered with his article “NuGet – A Powerful way to share your code”. While focused on NuGet, it’s a nice summary of why you want to use a package manager in your projects. Xiao Ling has a step-by-step post on creating and publishing .NET Core packages.

Building things in Unity? Wondering what NuGet is? Ashley Davis has you covered with his introduction to using Unity and NuGet. The Unity solution templates don’t easily allow working with NuGet, but there are some easy workarounds. A good example is demonstrated, installing JSON.NET into a Unity project.

Have you been consuming NuGet, and just started looking into creating your own NuGet packages to share them with team mates or with the world? Learn about publishing your first .NET Core NuGet package with AppVeyor and MyGet  - Andrew Lock gives a good step-by-step tutorial on what you need in code, and how AppVeyor and MyGet can be used to build and distribute your code.

On a similar topic, Maarten Balliauw has a post on Building NuGet (.NET Core) using Atlassian Bitbucket Pipelines. Pipelines is Atalassian’s continuous integration service that runs on Docker and Linux. And since .NET Core is a first class citizen on that platform, why not use it to build and test NuGet packages?

NPM news

NPM news, curated by MyGetLet’s start on the tooling side. Node has gotten two new releases, 4.5.0 and 6.4.0. Mostly bugfixes, better profiling support and improvements in objects and function contexts for debuggers. On the npm side, there’s now 2.15.10 and 3.10.7, with improvements to how scoped dependencies are handled and several other bugfixes.

Did you know the two millionth package version was just published to npm? If you have as well, congratulations! This is a pretty epic milestone in the Node.js community.

Laurie Voss, COO at npm, has a great talk titled “Abstractions, npm past, present, future”. It covers what is npm and where it came from, where the ecosystem stands today and what the plans are for the future. Highly recommended!

New to node? Have a look at Node Hero’s blog post series! These thirteen articles cover everything from getting started with node and npm, to building a web app, security, monitoring and all other aspects of building a node application.

Npmjs.org added web hook support a while back. Julian Gruber did a proof-of-concept where updated dependencies are automatically deployed in the application. Not the best idea, given that your deployment may break because of an updated dependency, but still quite cool. Package update? Deploy!

Into the Internet of Things? One such thing is the International Space Station! Dave Johnson has a nice post Node.js IoT: Tracking the ISS through the Sky where he uses JavaScript to capture GPS coordinates from the IIS and compares it to your home location to create a real-time tracker.

We’re thinking about doing this type of post each month. Let us know if you’d like that or not, using the comments below or reach out on Twitter.

Happy packaging!

Keeping feeds clean with retention rules

MyGet Package Retention Rules help clean up your NuGet npm feedMany developer teams use MyGet for storing their continuous integration and/or nightly builds of NuGet, npm, Bower and VSIX packages. As more and more packages get added, it may become harder to manage them all. Some packages may be used in projects, while others are not. Let’s go over the options available for housekeeping.

By default, MyGet keeps all package versions available on our feeds. Every package pushed is there forever, unless manually removed or removed by package retention. By setting retention rules, it is possible to automatically trim the list of packages to X latest packages, keeping into account package usage in projects and package dependency trees.

Configuring retention rules

Retention rules are defined per feed. Some feeds may have more aggressive retention rules defined, other may not have them enabled at all. From the Retention Rules, we can define:

  • the maximum number of stable versions to keep
  • the maximum number of prerelease versions to keep
  • whether to keep depended packages or not – enabling this makes sure package restores always complete successfully by keeping the dependency tree in its entirety
  • whether to allow removal of packages that have downloads – enabling this option ensures that packages that are being used in projects never get deleted

Setting retention rules

Keeping a specific package around

Retention rules are quite brute-force: they will always remove all packages that match the configured rules. Luckily, MyGet lets us “pin” packages which we want to keep around. For example, we may want to only keep the latest 10 pre-release versions while still keeping around the 20th pre-release version we’re still using in our projects.

From the package details page, we can define which package versions should never be considered by retention rules by using the Pin button next to the package.

Pinning packages so they do not get removed

We can pin package per version, or all versions at once using the button at the top of the Package History list. Of course, we can also Unpin packages using the same approach. Once a package is unpinned, retention rules are allowed to remove them.

Custom retention rules using web hooks

Using the built-in retention rules may not be enough. For example, what if we want to run retention rules based on other conditions than the latest version? What if we want to only remove packages when there is a full moon? Using web hooks, we can subscribe to certain feed events (like “package added”) and run our custom logic to optionally remove packages from our feed. We have a complete example available that helps getting started with web hooks.

Learn more about package retention in our documentation.

Happy packaging!

Dropbox as a package source for NuGet, npm, Bower and VSIX packages

Wouldn’t it be awesome if creating a NuGet, npm, Bower or VSIX feed was as easy as just copying packages into a Dropbox folder? Awesomeness is here: we’ve added Dropbox as a package source type to MyGet. This allows us to link a Dropbox folder to a MyGet feed and automatically upload packages so they can be consumed with the popular package managers out there.

Synchronizing NuGet packages with Dropbox

The Dropbox package source makes it easy to move packages into MyGet. For example, migrating from a network share to MyGet is as easy as copy-paste. Have a build server that drops artifacts into a Dropbox folder? MyGet will add the synchronized artifacts to your feed. Right now we download packages from Dropbox on a schedule (every 15 minutes).

Give it a try and let us know how it goes – feedback is welcome through the comments below or via the MyGetTeam Twitter account.

Happy packaging!

Package details showing GitHub project README

We’re happy to introduce a few user interface enhancements which have been available for all users of npm private feeds on MyGet. We’ve now rolled these out to the package details page for NuGet, npm, Bower and Vsix packages. These pages now display all “at-a-glance” information on the right. Package owners, authors, license information and downloads can be seen from here.

The wider part of the package details page now displays the README.md contents retrieved from GitHub. That is, if the GitHub repository is accessible for us. This makes it easier for consumers of your feed to see installation instructions, links to documentation and so on from the package details page.

MyGet showing GitHub readme contents on package details page

We're looking forward to hearing your feedback through the comments below. Or tweet us via @MyGetTeam.

Happy packaging!

Working with a private npm registry in Azure Web Apps

Using Azure Web Apps, we can deploy and host Node applications quite easily. But what to do with packages the site depends on? Do we have to upload them manually to Azure Web Apps? Include them in our Git repository? None of that: we just have to make sure our app’s package,json is checked in so that Azure Web Apps can install them during deployment. Let’s see how.

Installing node modules during deployment

In this blog post, we’ll create a simple application using Express. In its simplest form, an Express application will map incoming request paths to a function that generates the response. This makes Express quite interesting to work with: we can return a simple string or delegate work to a full-fledged MVC component if we want to. Here’s the simplest application I could think of, returning “Hello world!” whenever the root URL is requested. We can save it as server.js so we can deploy it later on.

var express = require("express"); var app = express(); app.get("/", function(req, res) { res.send("Hello world!"); }); console.log("Web application starting..."); app.listen(process.env.PORT); console.log("Web application started on port " + process.env.PORT);

Of course, this will not work as-is. We need to ensure Express (and its dependencies) are installed as well. We can do this using npm, running the following commands:

# create package.json describing our project npm init # install and save express as a dependency npm install express --save

That’s pretty much it, running this is as simple as setting the PORT environment variable and running it using node.

set PORT=1234 node server.js

We can now commit our code, excluding the node_modules folder to our Azure Web App git repository. Ideally we create a .gitignore file that excludes this folder for once and for all. Once committed, Azure Web Apps starts a convention-based deployment process. One of the conventions is that for a Node application, all dependencies from package.json are installed. We can see this convention in action from the Azure portal.

Azure Deploy Node.JS

Great! Seems we have to do nothing special to get this to work. Except… What if we are using our own, private npm modules? How can we tell Azure Web Apps to make use of a different npm registry? Let’s see…

Installing private node modules during deployment

When building applications, we may be splitting parts of the application into separate node modules to make the application more componentized, make it easier to develop individual components and so on. We can use a private npm registry to host these components, an example being MyGet. Using a private npm feed we can give our development team access to these components using “good old npm” while not throwing these components out on the public npmjs.org.

Imagine we have a module called demo-site-pages which contains some of the views our web application will be hosting. We can add a dependency to this module in our package.json:

{ "name": "demo-site", "version": "1.0.0", "description": "Demo site", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "author": "", "dependencies": { "express": "^4.13.3", "demo-site-pages": "*" } }

Alternatively we could install this package using npm, specifying the registry directly:

npm install --save --registry https://www.myget.org/F/demo-site/npm/

But now comes the issue: if we push this out to Azure Web Apps, our private registry is not known!

Generating a .npmrc file to work with a private npm registry in Azure Web Apps

To be able to install node modules from a private npm registry during deployment on Azure Web Apps, we have to ship a .npmrc file with our code. Let’s see how we can do this.

Since our application uses both npmjs.org as well as our private registry, we want to make sure MyGet proxies packages used from npmjs.org during installation. We can enable this from our feed’s Package Sources tab and edit the default Npmjs.org package source source. Ensure the Make all upstream packages available in clients option is checked.

(more details on this feature in the documentation on using MyGet with npm)

Next, register your MyGet NPM feed (or another registry URL). The easiest way to do this is by running the following commands:

npm config set registry https://www.myget.org/F/your-feed-name/npm npm login --registry=https://www.myget.org/F/your-feed-name/npm npm config set always-auth true

This generates a .npmrc file under our user profile folder. On Windows that would be something like C:\Users\Username\.npmrc. Copy this file into the application’s root folder and open it in an editor. Depending on the version of npm being used, we may have to set the always-auth setting to true:

registry=https://www.myget.org/F/demo-site/npm //www.myget.org/F/demo-site/:_password="BASE64ENCODEDPASSWORD" //www.myget.org/F/demo-site/:username=maartenba //www.myget.org/F/demo-site/:email=maarten@myget.org //www.myget.org/F/demo-site/:always-auth=true

If we now commit this file to our git repository, the next deployment on Azure Web Apps will install both packages from npmjs.org, in this case express, as well as packages from our private npm registry.

Installing node module from private npm registry

Happy packaging!

Automatically add NuGet, npm and Vsix packages from Visual Studio Online to MyGet

For over a year now, MyGet has had great Visual Studio Online (VSO) integration. We support adding VSO git repositories into build services, running convention-based builds that convert freshly pushed source code into NuGet, npm or Vsix packages. With the Visual Studio 2015 release cycle, Microsoft released a new build system for Visual Studio Online. The artifacts generated from a build can be automatically added to a MyGet feed by adding a Visual Studio Online package source, both from classic XAML-based VSO builds as well as the new build system.

From a MyGet feed, we can use the Package Sources | Add package source | Visual Studio Online build definition button to add a Visual Studio Online build definition. The first time we do this, we’ll have to grant access to our VSO instance.

MyGet Visual Studio build artifact

Once access is granted, MyGet will fetch a list of team projects and their builds. MyGet supports all sorts of build definitions, whether a classic XAML-based build or the new VSO “build vNext”. We can pick the team project we’re interested with, select the build definition, and depending on the VSO subscription we can also choose to post a message to a VSO team room whenever packages from a build are added to MyGet.

Publish NuGet package from Visual Studio Online to MyGet

Once we trigger a build in VSO, whether by checking in code or manually, MyGet will automatically add the generated artifacts to the current feed. Of course, we have to make sure our VSO build produces one or more .nupkg (NuGet), .tgz (npm) or .vsix (Vsix) artifacts (the Publish Build Artifacts build step will be needed for this). To run convention-based builds we can always use MyGet Build Services, too.

We're looking forward to hearing your feedback through the comments below. Or tweet us via @MyGetTeam.

Happy packaging!

Working with scoped npm packages and MyGet private registry

When we introduced npm support on MyGet last month, we did not yet have support for scoped packages. Today, we’re pleased to announce full support for them!

Scoped packages are packages that are "scoped" to a specific registry. E.g. all packages scoped @acmecorp may be retrieved from a MyGet npm registry feed, while other scopes and non-scoped packages flow in from the default npm registry.

Creating a scoped package

A scoped package can be created by setting the name property in package.json file correctly, for example:

{
  "name": "@acmecorp/awesomeapplication",
  "version": "1.0.0"
}

Dependencies can be scoped as well:

{
  "name": "@acmecorp/awesomeapplication",
  "version": "1.0.0",
  "dependencies": {
    "@acmecorp/awesomepackage": "1.0.0"
  }
}

More information on scoped packages is available from the npm docs.

Publishing a scoped package

Scopes can be associated with a specific registry. This allows for seamless mixing of packages from various npm registries.

Let's associate the scope @acmecorp with the https://www.myget.org/F/your-feed-name/npm/ npm registry feed. We can do this manually, by adding the following to our .npmrc file:

@acmecorp:registry=https://www.myget.org/F/your-feed-name/npm/
//www.myget.org/F/your-feed-name/npm/:_password="base64encodedpassword"
//www.myget.org/F/your-feed-name/npm/:username=someuser
//www.myget.org/F/your-feed-name/npm/:email=someuser@example.com
//www.myget.org/F/your-feed-name/npm/:always-auth=true

It's probably easier to generate these entries from the command line by running:

npm config set @acmecorp:registry=https://www.myget.org/F/your-feed-name/npm/
npm login --registry https://www.myget.org/F/your-feed-name/npm/ --scope=@acmecorp
npm config set always-auth true --registry https://www.myget.org/F/your-feed-name/npm/

From now on, we can publish and consume any package that has the @acmecorp scope. Npm will automatically direct requests to the correct registry.

Happy packaging!

P.S.: We have VSIX support coming as well. Let us know if you want to enroll in the preview.

MyGet now offers NuGet, Npm and Bower registries

pmsWith our latest MyGet release, we’ve added support for npm and bower registries. We’ve always been very focused on building a great story around NuGet and decided it was time for Npm and Bower enthusiasts to get a similar experience.

Adding npm and Bower support was high on our wish list and that of our users. Many developers are doing only front-end development and need a public or private npm registry. Others are working with DNX (the new name for ASP.NET 5 or ASP.NET vNext) and combine NuGet, npm and Bower. It feels good to be able to support them all!

To help you get started, we’ve prepared a few short tutorials that help you get started on MyGet with these package managers:

Oh and build services now also packages node modules! Just point MyGet to your GitHub repository and we’ll package your npm packages, too.

We really look forward to hearing your feedback on this!

Happy packaging!