What's coming to ngx-deploy-npm V8

ngx-deploy-npm is continuing to evolve. With the release of version 8, the library is set to undergo significant changes that will delight developers waiting for some much-needed upgrades. In this blog post, we will explore what's new in the upcoming version, the motivations behind these changes, and how they will benefit the community of developers who rely on this library to simplify the publishment of their libraries.

TL;DR

# Run Migrations
nx migrate ngx-deploy-npm
nx migrate --run-migrations

# Review changes 👀
# Commit changes

ngx-deploy-npm History 📜

Knowing some of this plugin's origins is meaningful to understand the upcoming changes. Nearly four and a half years ago, this plugin was born, but not as we know it today; at its dawn, it was an Angular Builder to publish Angular Libraries to NPM. It was designed to work on Angular Workspaces. (now, you know why the ngx prefix is on the plugin's name).

Back then, the standard way to publish an Angular Library was:

• Compile your library in production mode
• Step on dist folder
• run npm publish

And ngx-deploy-npm automated those steps to simplify Angular libraries publishment.

We later decided to support Nx Workspaces to open it to publish any kind of library to NPM, migrating the Angular Builder to an Nx Plugin. At that time, we could manage both workspaces with (almost) the same code. Documentation was written for both workspaces, and integration tests were implemented in our publishment process to ensure everything worked as expected for both workspaces.

Upcoming breaking changes 🔥

Drop support for Angular workspaces 🅰️

The Angular workspace support started to be a load for the maintainers. Several times, the compatibility bridge Nx Devkit offered began to crumble until it didn't work anymore.

The Nx ecosystem has continued evolving, and some of the original designs don't quite fit nowadays in Nx, but they do on Angular workspaces. That difference between both ecosystems makes us understand that to continue offering support for Angular workspaces, we must create and maintain two packages with separate approaches that benefit each workspace.

We have learned in these four years about maintaining packages that the work of a maintainer is hard. Maintaining two different NPM Packages would require considerable effort. We decided to focus on what brings the most value to our current users, and Nx Workspaces is the best way to do that.

Also, we wrote a script to help us determine which percentage of our current users are using an Angular workspace, and the results were that a shallow portion of our users are using an Angular Workspace.

Alternatives

We suggest migrating to Nx workspaces as an alternative to continue using ngx-deploy-npm. A stand-alone approach of Nx workspaces is an option that you should consider.

Removing the internal build process 🏗️

Since the project's early days, we've built the library before publishing. This process has been made using an internal process to accomplish it. We are removing it mainly for a couple of reasons:

• It hardcodes the build target; if your build target is different, there is no way to change it.
• The devkit function used to launch the build doesn't spawn the task orchestrator or any of that, so dependencies are not ran and caching is not considered (see nrwl/nx#19531). Making it not so great if you have a composed build process, users are forced to do a workaround to bypass that limitation and use the dependsOn Nx feature instead.

This change means that everything related to that feature will be gone. The options noBuild and buildTarget will be removed in favor of dependsOn, which is more flexible, declarative, and cache-friendly.

Removing auto dist folder detection and making the distFolderPath option mandatory. 📦

In its origins, when we only supported Angular libraries, the dist folder path was found in one place. Now that we can support multiple library generators, finding the dist folder path is challenging since there is no standard on where that information should be found.

To make the library source code smaller and easier to maintain, we decided to drop the auto dist detection and bring these breaking changes:

• The option distFolderPath is required for installation and deployment.
• In the installation generator, we will remove the option projects in favor of the new one project.

How do you prepare for V8?

We created migration scripts to do all the required changes for you automagically.

nx migrate ngx-deploy-npm
nx migrate --run-migrations

We have explained all the changes and their motivations to guide you through this new release in case you have trouble running the migration scripts.

After publishing this post, we plan to release version 8 in a couple of days.

---

In conclusion, the upcoming version of ngx-deploy-npm is set to undergo significant changes that will bring much-needed upgrades to the library.

• Removal of dist folder path detection.
  • distFolderPath option is now mandatory.
• Drop support for Angular workspaces.
• Drop the internal build process in favor of dependsOn.

These are among the breaking changes that developers can expect. Overall, these changes aim to provide a better experience for the community of developers who rely on ngx-deploy-npm to simplify their libraries' publishment. Also, make the ngx-deploy-npm core simpler.

If this project has positively impacted you, consider supporting it by:

• Giving it a star ⭐ on GitHub
• Start a discussion 💬 and tell everybody how unique this project is.
• Make a donation 🫶

Comments

[Diego Juliao]

Interesting related update.
Since ngx-deploy-npm no longer supports Angular CLI workspaces, I decided to remove it from the Angular Official Documentation.

github.com/angular/angular/pull/53999