Forem: Diego Juliao

NPM peerDependencies in Depth: A Comprehensive Introduction

Diego Juliao — Sat, 19 Oct 2024 07:35:20 +0000

As Javascript developers, we all know two different dependencies in our projects, dependencies and devDependencies, but what about peerDependencies?

In this series, we will examine this less common dependency in Javascript. We will study what they are, what I need to know about as a library user, and what best practices are for library authors.

What are dependencies in NPM

Let's recap the different common types:

dependencies: these are the tools used in your application; a good example is react, angular, and express. When your application is in production, the code of the libraries on dependencies will run under the hood and power your application.
devDependencies: You will use these utilities to build your application. Here, you will find libraries to compile or parse your code and libraries to run your test.

What are `peerDependencies`

Authors specify specific libraries as peerDependency when they require them to be installed in the workspace/project for everything to work as expected. They tell NPM (and the developers installing the library) that the package requires another package's specific version (or range of versions) to function correctly. Still, the user is responsible for installing and managing that dependency.

Let's imagine an example: You are creating a utility for your favorite framework, which should be installed in the environment where your library will be running. The way to accurately specify this scenario is using the NPM peerDependency feature. It provides a clear guideline for the seamless integration of your library.

This practice is particularly common in libraries that function as "plugins," as they need to indicate the workspace requirements for proper functionality.

Real Example of `peerDependency`

Let's analyze a popular React library, react-datepicker; if we look at how its package.json looks today, we can tell that we require at least React version ^16.9.0 for react-date picker to work correctly.

"peerDependencies": {
  "react": "^16.9.0 || ^17 || ^18",
  "react-dom": "^16.9.0 || ^17 || ^18"
},

If we fail to comply with this requirement, unexpected behavior will arise.

The Challenges `peerDependencies` Address

Version conflicts occur when packages in a project rely on different versions of the same library. This can lead to errors, especially for libraries like React, where sharing the same instance is crucial for state management and component communication. Without peerDependencies, multiple library versions could be installed, resulting in unexpected behavior.

To prevent these issues, peerDependencies allow package authors to specify which version of a dependency their package requires without directly installing it. This shifts the responsibility to the developer using the package, ensuring they install a single, compatible dependency version. For example, libraries like react-datepicker and react-router use peerDependencies to ensure they work seamlessly with the same version of React in the project.

Another Example

Imagine this scenario: You're creating a library to share a fancy operator for rxjs. If you set rxjs as a dependency instead of a peerDependency, your library will install its own version of rxjs. This might not seem like a big deal at first, but in reality, it can lead to version conflicts.

If the project that installs your library already uses a different version of rxjs, it could cause significant issues. The application might end up with two instances of rxjs (one from your library and one from the project itself). Since rxjs relies heavily on shared observables and subscriptions, having two versions running simultaneously can result in unpredictable behavior, such as streams not synchronizing properly or missing events.

By using peerDependencies instead, you can avoid this problem. Your package will signal to the project that it expects a specific version (or a range) of rxjs to be present, but it won’t install its own version. This way, the project will use a single version of rxjs shared by your library and other parts of the codebase, ensuring everything runs smoothly and in harmony.

Conclusion

peerDependencies may not be as commonly discussed as dependencies or devDependencies, but they play a critical role in ensuring compatibility and avoiding version conflicts in complex projects. By clearly defining which version of a shared dependency a library needs without directly installing it, peerDependencies allow developers to maintain control over their project environment.

The goal of this first post is to create a good understanding foundation of peerDependencies. In the next chapter of this series, we will explore in a more practical way the different aspects of peerDependencies as a user of libraries with peerDependencies, how to overcome common problems, and how they behave in different javascript package managers.

What's coming to ngx-deploy-npm V8

Diego Juliao — Tue, 16 Jan 2024 21:01:24 +0000

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 🫶

7 VSCode Extensions to Boost Your Performance as an Angular Developer

Diego Juliao — Wed, 28 Sep 2022 18:03:27 +0000

Extensions on VSCode are invaluable tools for us developers to turn repetitive manual tasks in a few clicks or key bindings ⚡, do complex operations automagically ✨, and increase our development satisfaction by providing us a whole new experience on gray areas 🚀.

Today, we will see 7 VSCode extensions that will increase our performance and enhance our experience with Angular.

Nx Console

This is my favorite so far 😍. It was previously known as Angular Console. The description of this plugin has everything we need to know:

“Spend less time looking up command-line arguments and more time shipping incredible products.”

This extension is a UI for the Angular CLI. You will have all schematic parameters with their description available to decide better what fits your current needs. It’s an excellent opportunity to discover what the Angular CLI offers; it’s encouraged to mess around with the parameters’ values because everything runs with the --dry-run option as default (no changes applied). Still, the effects of those changes are displayed in a console below to decide what fits you better.

Don’t get confused or intimidated if you don’t know Nx. It works like a charm on Angular Workspaces.

Here, you can see how to generate an Angular Component.

angular2-switcher

Simple but powerful, it allows navigating between the files using hotkeys on your Angular component. You can navigate the template, the component, styles, or the tests file with a couple of keys. It allows you to avoid opening the explorer, locating your component across tens of folders, and, finally, the file you were looking for.

This is the key combination:

	Windows	macOS
Switch to HTML	Alt+O	Shift+Alt+O
Switch to CSS	Alt+I	Shift+Alt+I
Switch to ts	Alt+U	Shift+Alt+U
Switch to spec.ts	Alt+P	Shift+Alt+P

Angular Language Service

This extension provides autocompletion on the templates of our components. No more awkward moments of try and error. Now, you will have a tool to communicate the HTML with your component. All the methods will be at your fingertips.

Code Spell Checker

How often has the QA discovered a wrong spelling world on an interface you have worked on and held a ticket from its deadline? How many times was the backend “broken”, and the problem was because you incorrectly spelled a parameter? Say goodbye to those embarrassing moments and detect all the slips on the spot.

Bookmarks

Are you dealing with a complex project and lost your path among all the files you need to have open to tracking a feature? Dealing with very long files and lost focus on the long scrolling? Stay focused on what matters to you by putting bookmarks on the lines you want to stay concentrated on and start navigating between them.

Jest Runner

Jest has been gaining terrain on the Angular ecosystem, especially on Nx, where it’s the default test runner. With this extension, you can run a specific test causing you troubles. Also, you can run that particular test in debug mode for a more detailed inspection.

Angular snippets

I recommend using two extensions, Angular Snippets (Version 13) and Angular 10 Snippets — TypeScript, Html, Angular Material, ngRx, RxJS & Flex Layout. Both offer snippets for your Angular day-to-day work generate in seconds complex structures for Angular itself (components, modules, pipes, ngFor, ngIf, etc.), NgRx, Material Design, RxJs, and Testing.

Extensions are good instruments to improve our performance as developers. I love that when something automates a process, I can liberate some thinking load in a particular area and stay focused on what matters, building excellent products.

Do you have one extension that has changed your life? Let us know in the comments.

About HeroDevs

HeroDevs is a software engineering and consulting studio that specializes in frontend development. Our team has authored or co-authored projects like the Angular CLI, Angular Universal, Scully, XLTS — extended long-term support for AngularJS, Ng-conf, and many others. We work with fast-growing startups and some of the world’s largest companies like Google, GE, Capital One, Experian, T-Mobile, Corteva, and others. Learn more about us at herodevs.com

i3wm Screenshot Shortcuts

Diego Juliao — Sat, 26 Mar 2022 20:53:35 +0000

Have excellent screenshot shortcuts in your i3wm.

Feature	Shortcut
Full Screen	`PrtScrn`
Selection	`Shift` + `PrtScrn`
Active Window	`Super` + `PrtScrn`
Clipboard Full Screen	`Ctrl` + `PrtScrn`
Clipboard Selection	`Ctrl` + `Shift` + `PrtScrn`
Clipboard Active Window	`Ctrl` + `Super` + `PrtScrn`

All the screenshots are saved on ~/Pictures/CURRENT_DATE.
The key super refers to the modifier key (window/command or alt by default depending on config).

Requirements

maim
xclip
xdotool

Set-up

Set this on your i3 config file ~/.i3/config.

## Screenshots
bindsym Print exec --no-startup-id maim "/home/$USER/Pictures/$(date)"
bindsym $mod+Print exec --no-startup-id maim --window $(xdotool getactivewindow) "/home/$USER/Pictures/$(date)"
bindsym Shift+Print exec --no-startup-id maim --select "/home/$USER/Pictures/$(date)"

## Clipboard Screenshots
bindsym Ctrl+Print exec --no-startup-id maim | xclip -selection clipboard -t image/png
bindsym Ctrl+$mod+Print exec --no-startup-id maim --window $(xdotool getactivewindow) | xclip -selection clipboard -t image/png
bindsym Ctrl+Shift+Print exec --no-startup-id maim --select | xclip -selection clipboard -t image/png

You may want to remove the default or any other screenshot shortcuts to prevent errors.
Don't forget to reload your window manager super+ shift+ c.

The source of this information is from my gist My i3 shortcuts to take screenshots.

Improve your GitHub Actions Workflow execution time by 32% ⚡

Diego Juliao — Wed, 08 Dec 2021 07:25:27 +0000

My Workflow

There is a process that gets repeated most of the time across your workflow, a process that is expensive in time speaking; it takes 25 seconds to complete. This process is essential, and without it, you can not do almost anything.

I'm talking about installing the dependencies for your project, npm install for node projects. Without it, you can not build, test, lint or do almost any other operation on your workflow.

We can do something straightforward to downgrade those 25 seconds to 14.3 (an improvement of almost 60%!😮). You only need to apply cache to the dependency installation (npm install). Those 10 seconds saved across all your jobs will add up to 32% improvement.

The secret of achieving an execution improvement of 32% is to be consistent, apply DRY. Every time you need to perform the dependency installation, you need to be sure to use the same set of steps.

Github actions allow us to be consistent super-easy with custom actions. We can define an activity with all the steps needed and then reuse it every time with just one line of code.

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

This is the actual action using yarn as the package manager.

# .github/actions/setup/action.yml
name: Setup
description: Setup Node.js, cache and install dependencies
inputs:
  node-version:
    description: Node.js version
    required: false
    default: '16'
runs:
  using: composite
  steps:
    - name: Install Dependencies
      uses: actions/setup-node@v2
      with:
        cache: yarn
        node-version: ${{ inputs.node-version }}
        registry-url: https://registry.npmjs.org
    - name: yarn install
      shell: bash
      run: yarn --frozen-lockfile --no-progress --non-interactive --prefer-offline

To use it on any job:

jobs:
  any-job:
    runs-on: ubuntu-latest
    steps:
      - name: Get code to get access to custom our actions
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Install Dependencies
        uses: ./.github/actions/setup

      - name: Doing any-job
        run: npm run any-job

Check out the workflow on an actual project.

dianjuar / improve-workspace-execution-32

Improve your workflow execution by 32% just by caching the yarn installation

Improve your Workflow execution time by 32% ⚡

Using cache on dependency installation to achieve up to 32% of execution improvement (GitHub Actions)

Check blog post on Dev.To

View on GitHub

Additional Resources / Info

This discovery was formulated, tested, and explained with numbers statically correct on ngx-deploy-npm project.

@jscutlery/semver project is implementing this improvement

Importing modules in JavaScript, are we doing it right?

Diego Juliao — Tue, 31 Aug 2021 21:39:43 +0000

We, as Javascript developers need to use libraries in our day to day, it simplifies our work a lot. Nowadays we mostly do it in this way:

import * as lib from 'amazing-lib'
import { func1 } from 'amazing-lib'

If we quickly analyze it, in the first statement we are importing everything and putting it on a variable called lib, on the second, we are importing everything again and destructuring only what we need; what about all the other code that I'm not using?

Will not all the unused library's code end up on the final bundle making my application unnecessary heavier?

Today you will learn how to improve your bundle size just by changing the way you import. After this, you are going to be able to detect a simple optimization opportunity for your bundle!

TL; DR

Verify if the library has support for ES6 and you can import freely, you will get always the best result 🙆‍♂️. If it doesn't ⚠️, you need to import using cherry-picking.

Can we import as we want without consequences?

When we compile our front-end apps, there is a process that Webpack applies called Tree Shaking. Basically, is code elimination, the code that is not being used by anyone. This process prevents having dead code in our final bundle, making it lighter and the application is going to load faster for our users!

Let's analyse this:

import * as lib from 'amazing-lib'
import { foo } from 'amazing-lib'

In both cases all the library content is being imported, the first place is the easiest to spot, all the library's content is being assigned to the variable lib, in the second case we are just applying destructuring to the library's content to get what we need. Thanks to Tree Shaking all the unused code doesn't end up on our bundles.

So, thanks to Tree Shaking I'm excused and I can import however I want and all the unused code imported from the library will be removed automagically?

Is not always the case

There is a scenario when Tree Shaking is not going to be able to detect what is dead code having as consequence to remove nothing.

Scenarios

ES6

ECMAScript 2015(aka ES6) Module Syntax; it sounds complex, but it's something really popular nowadays. It's just a syntax to import a JS module, it looks like this:

import { foo } from 'awesome-lib'
import { bar } from '../utils'
import * as lib from '../utils'

export const justAConst = 'foobar'

When you are using a library that has ES6 Module Syntax compatibility, you don't need to worry, import as will, Tree Shaking have you covered 😉. In fact, is the only module syntax that Tree Shaking supports, let's take a look at the documentation:

Tree shaking is a term commonly used in the JavaScript context for dead-code elimination. It relies on the static structure of ES2015 module syntax, i.e. import and export...

The webpack 2 release came with built-in support for ES2015 modules (alias harmony modules) as well as unused module export detection...

If you are completely new about 👉 JS Modules

No ES6 module syntax

A library can be delivered (packaged) with other module systems different than ES6, even though if its source code uses ES6 module syntax, a compilation process could be implemented to only support CommonJS for example. The projects written using pure JS (with no transpilation process (Babel, TypeScript)) that uses the CommonJs module system is another example.

So, no ES6 module syntax present = no Tree Shaking. The only way to have a healthy bundle when dealing with libraries with no ES6 is importing using a technique called cherry-picking, you need to specify the absolute path to the file that contains the info needed.

import { small } from 'common-js-lib/small';

Downsides of cherry-picking

You need to know the path to the module needed. (Your IDE could help in this quest)

You need to specify each one of the imports that you need, ex:

import has from 'lodash/has';
import capitalize from 'lodash/capitalize';
import lastIndexOf from 'lodash/lastIndexOf';

As a maintainer, you may want to have a nice and easy-to-use scaffolding design to detect with ease something in your lib. This needs to be designed, implemented, and maintained.
You may forget to do it, making your bundle unnecessary heavier. ESLint could help you to import correctly.

Performance Test

Having the theory learned I decided to prove all this. What I did was create some libraries with different module support, create several front-end apps on React and Angular¹ to test if Tree Shaking really does its job.

The libraries created were simple, they export two variables small and big. small contains one dog 🐕 (small = '🐕'), but big has 1646400 dogs (big = '🐕🐕🐕🐕🐕🐕🐕🐕🐕...'). This is going to make big to be 6.3 megabytes of weight.

Only small is going to be use at all time, so if big sneaks into the final bundle we are going to notice it on sight!.

Healthy Bundle

This how a healthy bundle looks like:

Smelly Bundle 🤢

The smelly one! You can notice a big white box that represents big and represents 96.7% of the application size:

The Results

The results were as expected, if your library has to offer ES6 module syntax, Tree Shaking will do its job. If not, cherry-picking was the only way to get a healthy bundle.

Here is the repo if you are curious dianjuar/how-to-import. All this was created in a Monorepo using Nx, the library's npm publishing was mocked using yalc. The bundle analysis was made using source-map-explorer.

Also, I wanted to make this test with popular libraries, so this is what I got, importing as import { whatINeed } from 'popular-lib'

Library	Healthy Bundle
lodash	❌
moment	❌
rxjs	✅
lodash-es	✅
date-fns	✅
@angular/core	✅
@angular/material	✅
react	✅
react-dom	✅
@material-ui/core	✅
@fortawesome/react-fontawesome	✅

Useful Tools

Along with this experiment, I was using the VsCode extension Import Cost and was precise along with the result. With the extension, you will be able to see right away how much an import will cost to the bundle. It will not tell you when you are getting a healthy or smelly bundle, but you can tell when an import cost is sus.

Gif extracted from the README of Cost Import

Conclusion

Tree Shaking have you covered! You can import however you want and you will be getting a healthy bundle if and only if the library has support for ES6 Module Syntax (import and export).

You can make your bundle unnecessary heavy if you don't cherry-pick the imports on libraries without ES6 module support, like lodash.

Import Cost can help you to spot an import that needs some refinement.

The experiment is agnostic to the Framework or Library used, if webpack is involved in the bundling it would take the same effect. ↩

Importando módulos en Javascript, lo estamos haciendo bien?

Diego Juliao — Tue, 31 Aug 2021 15:24:17 +0000

Todos los desarrolladores Javascript usamos librerías en nuestro día a día, facilita mucho nuestro trabajo. Hoy en día lo hacemos mayormente de esta manera:

import * as lib from 'super-lib'
import { func1 } from 'super-lib'

Si analizamos rápidamente esto, en la primera sentencia estamos importando todo y asignándolo a la variable lib, en el segundo, estamos importando todo nuevamente pero usando destructuring obtenemos solo lo que queremos; qué sucede con todo el código que no se está usando?

¿Todo el código que no se está usando terminará en el bundle final haciendo mi aplicación innecesariamente pesada?

Hoy, aprenderemos cómo mejorar el tamaño de un bundle simplemente cambiando la manera en que importamos. Después de leer esto, serás capaz de detectar una simple oportunidad de optimización para el bundle.

TL; DR

Verifica si la libería tiene soporte para ES6 y serás capaz de importar como quieras, siempre obtendrás el mejor resultado 🙆‍♂️. Si no lo soporta ⚠️, tendrás que importar usando cherry-picking.

¿Podemos importar de cualquier manera sin consecuencias?

Cuando compilamos aplicaciones front-end, hay un proceso que Webpack aplica llamado Tree Shaking. Básicamente, es eliminación de código, el código que no está siendo usado por nadie. Esto es un proceso que previene que código muerto termine en nuestro bundle final, haciéndolo más liviano así las aplicaciones van a cargar más rápidamente para nuestros usuarios!.

Analicemos esto:

import * as lib from 'amazing-lib'
import { foo } from 'amazing-lib'

En ambos casos todo el contenido de la librería está siendo importado, en la primera línea es donde se observa más claramente, todo el contenido está siendo asignado a la variable lib, en la segunda línea estamos simplemente aplicando destructuring al contenido de la librería para obtener lo que queremos. Gracias a Tree Shaking todo el código que no es usado no termina en el bundle final.

Así que, gracias a Tree Shaking tengo un pase libre a importar como yo quiera y todo el código muerto importado de la librería será removido automágicamente?

No siempre es el caso

Hay un escenario cuando Tree Shaking no será capaz de detectar qué es código muerto, teniendo como consecuencia que no se removerá nada.

Escenarios

ES6

La Sintaxis de Modulo ECMAScript 2015(también conocido como ES6); suena complejo, pero es algo bastante popular en estos días. Es solo una sintaxis para importar un modulo Javascript, luce así:

import { foo } from 'super-lib'
import { bar } from '../utils'
import * as lib from '../utils'

export const justAConst = 'foobar'

Cuando usas una librería que ofrece soporte para para sintaxis ES6, no hay de qué preocuparse, importa libremente, Tree Shaking estará ahí 😉. De hecho, es con la única sintaxis de modulo que Tree Shaking soporta. Miremos a la documentación:

Tree Shaking es un término comúnmente usado en el contexto Javascript para la eliminación del código muerto. Él se apoya en la estructura estática de la sintaxis de modulo ES2015, esto es import y export...

El lanzamiento de Webpack 2 vino con soporte para los módulos ES2015 (también conocido como módulos de armonía) junto a la detección de módulos exportados que no están siendo usados...

Si eres completamente nuevo acerca de los 👉 Módulos JS

Sin sintaxis de modulo ES6

Una librería puede ser empaquetada con otro sistema de módulos diferente a ES6, un proceso de compilación pudo haberse implementado para soportar solo CommonJS por ejemplo. Los proyectos escritos usando Javascript puro (sin procesos de transpiración (Babel, TypeScript)) que usan unicamente CommonJs para gestionar sus módulos es otro ejemplo.

Así que, sin sintaxis ES6 significa no Tree Shaking. La única manera de tener un bundle saludable cuando se lidia con librerías sin soporte para la sintaxis de módulo ES6 es importar usando una técnica llamada cherry-picking, se necesita especificar la ruta absoluta al archivo que contiene la información que necesitamos.

import { small } from 'common-js-lib/small';

Inconvenientes del cherry-picking

Es necesario saber la ruta al modulo necesitado. (Tu IDE puede ayudar en esto)

Es necesario especificar uno a uno los módulos requeridos, ej:

import has from 'lodash/has';
import capitalize from 'lodash/capitalize';
import lastIndexOf from 'lodash/lastIndexOf';

Como autor de una librería, probablemente querrás un sistema de carpetas fácil de usar para detectar rápidamente algo en tu librería.
Puedes olvidar hacerlo y sin querer se hace el bundle innecesariamente más pesado. EsLint puede ayudarte a importar correctamente.

Test de Performance

Teniendo la teoría aprendida decidí probar todo esto. Lo que hice fue crear algunas librerías con soporte para diferentes módulos, crear algunas aplicaciones front-end con Angular y React¹ para probar si Tree Shaking estaba realmente haciendo su trabajo.

Las librerías creadas fueron simples, ellas exportan dos variables small y big. small contiene un perro 🐕 (small = '🐕'), pero big tiene 1646400 perros (big = '🐕🐕🐕🐕🐕🐕🐕🐕🐕...'). Esto hará que big pese 6.3 megabytes.

Únicamente será usado small todo el tiempo, así que si big logra escabullirse hasta el bundle se podrá notar de inmediato.

Bundle Saludable

Así es como un bundle saludable se ve:

Bundle Oloroso 🤢

El bundle oloroso! Puedes notar una gran caja blanca que representa el 96.7% de la aplicación:

Los Resultados

Los resultados fueron los esperados, si la libería tenía para ofrecer la sintaxis de módulos de ES6, Tree Shaking hará su trabajo. Si no, cherry-picking es el único camino hacia el bundle saludable.

Aquí está el repositorio si son de los curiosos dianjuar/how-to-import. Todo esto fue creado en un monorepo usando Nx, para simular la publicación del paquete en NPM se usó yalc. El análisis del bundle fue hecho con source-map-explorer.

Yo también quise aplicar este test a algunas librerías conocidas y esto fue lo que encontré al importar de la siguiente manera import { whatINeed } from 'popular-lib'

Librería	Bundle Saludable
lodash	❌
moment	❌
rxjs	✅
lodash-es	✅
date-fns	✅
@angular/core	✅
@angular/material	✅
react	✅
react-dom	✅
@material-ui/core	✅
@fortawesome/react-fontawesome	✅

Herramientas Útiles

Durante este experimento estuve usando la extensión de VsCode Import Cost y fue precisa paralelamente con los resultados. Con esta extensión podrán ver de manera inmediata cuánto costará el import en el bundle. No dirá directamente si estás teniendo un bundle saludable o no, pero te darás cuenta cuándo un import es sospechoso.

Gif extraído del README de Cost Import

Conclusión

Tree Shaking te tiene cubierto! Puedes importar como desees y siempre tendrás un bundle saludable si y solo si la librería tiene soporte para la sintaxis de módulos de ES6 (import y export).

Puedes hacer el bundle innecesariamente pesado si no haces cherry-pick al importar en librerías sin soporte de módulos ES6, como lodash.

Import Cost te puede ayudar a detectar un import que necesite algún refinamiento.

El experimento es agnóstico al framework o librería usada, si webpack está encargado de generar el bundle el resultado sería el mismo. ↩

Publish your libraries to NPM with one command (Angular and Nx)

Diego Juliao — Mon, 10 May 2021 07:00:41 +0000

To publish a library to NPM we have to do simple steps:

Build the library, compile it.
Change the version that you want to publish on the library's package.json
Run npm publish on the folder of your built library

This can be performed by hand or can be done by a couple of hours of creating a script that does the work for us to automate it. If we think about it, this is relatively easy to do but let's think about some considerations 🤔:

What if we don't have only one library but several because we are using the mono-repo approach?
What if is our fourth library and we are tired of writing/test/maintain the same thing over and over again?
What if we just don't want or don't have the time and patience to do so 😅?

With ngx-deploy-npm you can publish any kind of library on your Angular or Nx workspace with just one command.

By any kind I mean literally any kind of publishable library no matter the technology you use, Angular, React, Node, or NestJs 🚀.

You just need to have your library on an Angular or Nx workspace

TL;DR

Supposing that you have:

An Angular or Nx workspace with a publishable library
Already logged into NPM using npm login

Publish your package by:

Angular 🅰️	Nx 🐬
# Install (made only once) ng add ngx-deploy-npm # Publish ng deploy your-library	# Install (made only once) nx generate ngx-deploy-npm:install # Publish nx deploy your-library

Publishing your library to NPM with `ngx-deploy-npm`

Pre-steps

Have a workspace, Angular or Nx (it won't variate too much between them)
Have a publishable library in your workspace
Being already logged into NPM, npm login

No matter in which workspace you are, you have to do an installation of the builder (only made once) and then you can execute it to publish your library the times that you want.

Angular 🅰️

Angular Installation

First, we need to add this builder to our workspace, this can be done by just

ng add ngx-deploy-npm

This is going to detect all our libraries and modify your angular.json file to "install" this builder. You will notice the architect deploy was added to all our libraries on our workspace, it's going to look like this:

"deploy": {
  "builder": "ngx-deploy-npm:deploy",
  "options": {
    "access": "public",
    "buildTarget": "production"
  }
}

That is all the configuration needed to publish a package to NPM, now what’s left is the DEPLOY 🚀

Angular Publishing

ng deploy YOUR-LIBRARY-NAME

And done, your library is published to NPM 😊

Nx 🐬

With an Nx workspace, the procedure doesn't change that much, you have to "install" it first and then publish the times that you want.

Nx Installation

It doesn't change that much from the Angular Installation. It takes the same effect and has the same goal, kind of "install" the builder in your Nx Workspace by detecting all your publishable libraries (libraries that we created as such) and add the corresponding architect deploy to all of them. It can be done by:

nx generate ngx-deploy-npm:init

Nx Publishing

nx deploy YOUR-LIBRARY-NAME

And done, your library is published to NPM 😊

Nice Features 🤩

This is a wrapper of npm publish so all the parameters are available with the same name.

`--package-version`

You can set the future version of your library just using the argument --package-version, this will write the version that you passed on the package.json. Really convenient when you have a version pattern in your workspace.

`--build-target`

With this parameter, you can select which environment to build your library. Really convenient for Angular libraries that due to IVY they have a production environment.

`--dry-run`

Will not execute any operation, just to see how it will go. Very convenient to test and visualize without performing any action.

Publishing to private repositories 🔒

This builder is a wrapper of npm publish so just by having a well configured .npmrc file you can publish your packages anywhere. If you have the .npmrc file pointing to a private npm repository ngx-deploy-npm will publish your libraries there smoothly.

Accomplishments 🌟

🎉 ngx-deploy-npm is being referenced on the Angular Official Documentation on automatic deployment with the cli section along with other builders.
🎉 ngx-deploy-npm is also referenced on Nx Plugins official page.

Conclusion

ngx-deploy-npm is a tool that helps us to publish any kind of library to NPM just by one command if we have our libraries in an Angular or Nx Workspace. It helps us to automate the publishing process of our libraries making it really easy

Forem: Diego Juliao

NPM peerDependencies in Depth: A Comprehensive Introduction

What are dependencies in NPM

What are peerDependencies

Real Example of peerDependency

The Challenges peerDependencies Address

Another Example

Conclusion

What's coming to ngx-deploy-npm V8

TL;DR

ngx-deploy-npm History 📜

Upcoming breaking changes 🔥

Drop support for Angular workspaces 🅰️

Alternatives

Removing the internal build process 🏗️

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

How do you prepare for V8?

7 VSCode Extensions to Boost Your Performance as an Angular Developer

Nx Console

angular2-switcher

Angular Language Service

Code Spell Checker

Bookmarks

Jest Runner

Angular snippets

About HeroDevs

i3wm Screenshot Shortcuts

Requirements

Set-up

Improve your GitHub Actions Workflow execution time by 32% ⚡

My Workflow

Submission Category:

Yaml File or Link to Code

dianjuar / improve-workspace-execution-32

Improve your workflow execution by 32% just by caching the yarn installation

Improve your Workflow execution time by 32% ⚡

Additional Resources / Info

Importing modules in JavaScript, are we doing it right?

Will not all the unused library's code end up on the final bundle making my application unnecessary heavier?

TL; DR

Can we import as we want without consequences?

Scenarios

ES6

If you are completely new about 👉 JS Modules

No ES6 module syntax

Downsides of cherry-picking

Performance Test

Healthy Bundle

Smelly Bundle 🤢

The Results

Useful Tools

Gif extracted from the README of Cost Import

Conclusion

Importando módulos en Javascript, lo estamos haciendo bien?

¿Todo el código que no se está usando terminará en el bundle final haciendo mi aplicación innecesariamente pesada?

TL; DR

¿Podemos importar de cualquier manera sin consecuencias?

Escenarios

ES6

Si eres completamente nuevo acerca de los 👉 Módulos JS

Sin sintaxis de modulo ES6

Inconvenientes del cherry-picking

Test de Performance

Bundle Saludable

Bundle Oloroso 🤢

Los Resultados

Herramientas Útiles

Gif extraído del README de Cost Import

Conclusión

Publish your libraries to NPM with one command (Angular and Nx)

TL;DR

Publishing your library to NPM with ngx-deploy-npm

Pre-steps

Angular 🅰️

Angular Installation

Angular Publishing

Nx 🐬

Nx Installation

Nx Publishing

Nice Features 🤩

What are `peerDependencies`

Real Example of `peerDependency`

The Challenges `peerDependencies` Address

`ngx-deploy-npm` History 📜

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

Publishing your library to NPM with `ngx-deploy-npm`

`--package-version`

`--build-target`

`--dry-run`