Lazy-loading components (part IV - Publishing a module)
Tags: lazyloading, performance, javascript, webpack
Published: 2020-04-09 18:57:56

---
title: Lazy-loading components (part IV - Publishing a module)
published: true
description: The analysis before you decide your lazyloading strategy
tags: lazyloading, performance, javascript, webpack
series: lazyloading-architecture
---

If you've read the series until here, now you know why you want to lazy-load components to your pages or views and you know what are some of the decisions you may have to make, to have an effective strategy.

You have also extracted common style definitions from your component's stylesheets, to a commons package with the intention of importing it to multiple tenants, and even completely different projects.

You know that that package needs to include ONLY abstracts, so you're not deliberately importing code. Only definitions. And you know what the folder structure of that package looks like.

And now, we will publish it. Important: **this article assumes that you have git, node and npm globally installed in your system!!!** If you don't, you will have to do that first.


## Step 1: Move it to a new repository

The first thing you need to do is to move the abstract folder to a new repository. 

** Don't forget to initialize it as a new git repo executing**

`$ git init` 

in your terminal, so you can have version control.

## Step 2: Initialize it as an npm package

For that, run the following command (in the folder that should be your package root)

`$ npm init`

When you initialize a folder as a package, after a series of prompts, a `package.json` is added to your folder.

For the sake of explaining other tasks you need to complete, let's suppose you called this package **fe-scss-commons**

## Step3: Declare 3rd party dependencies you may have

This is when you should install any dependencies if you have them. I, for instance, almost always use [breakpoint-sass](http://breakpoint-sass.com/) in all my projects. I find it very efficient, to handle responsive behavior and media breakpoints. 

For that, run 

`$ npm install [your-dependency-name] --save`

**Pro-tip:** add `node_modules` to your .gitignore!

## Step 4: Configure npm registry

This part is particularly important if you are going to be publishing at a corporate repository private registry, behind a proxy.

Create a file called `.npmrc` at root level, and add the following to it:

`registry=https://path-to-your-corporate-registry`

**Important!:** If you are going to publish it to a private repository (such as Nexus, Gradle or even npm Enterprise, or the like), you need to have a user there, and `read-write` permissions for it.

If you're going to publish it to the public npm registry (make sure you are not publishing anything that needs to stay private), you also need an npm user.

You should also go back to your package.json and add this property:

`"publishConfig": {
    "registry": "https://path-to-your-corporate-registry"
  },
`

## Step 5: Log in to the registry

Now add your user, in order to publish your package

`$ npm adduser --registry=https://path-to-your-corporate-registry`

This will prompt you to add you username, password and email, for your registry.

`Username: myusername
Password: ******
Email: (this IS public) myusername@myregistry.url.com`

If you're successful, you will see the following message in your terminal

`Logged in as myusername on https://path-to-your-corporate-registry`

## Step6: Publishing your version

You for sure want to follow [semantic versioning rules](https://semver.org) to keep track of your package versions, and to make sure that previous versions can still be used as a dependency, hence not causing dependent projects to break.

If it's the first time you publish the package, if it's stable, you can go directly to version 1.0.0. If you're republishing, and to make sure you add the right version tag, execute

`$ npm version`

This command will return an object with the package name and version.  
In order to bump the version, run

`$ npm version *.*.*` (+1 according to [semantic versioning rules](https://semver.org) )

Then execute 

`$ npm publish` 

If everything goes right, you should see no errors and the last line in the console will print `package-name@version-number`, where the version-number is the one you defined.

# Step 7: Push the tags to your git repo

The last thing you need to do is to push the tags and the code, to your git repository

`$ git push --tags`
`$ git push`

This will ensure that, if you're working distributed, everyone gets the latest version to work on top for further changes.

## Note on CD/CI

Now you know how to manually publish this package, I recommend you try to integrate it to your CD/CI strategy. Publishing a new version should be integrated into your continuous deployment strategy and not be a manual task.

How you configure that, depends very much on what software you use for these integrations. I believe I should write an entire post on that ;)

## Step8: Using the package as a dependency

Ok! Now you have your shared abstracts published as an npm package. For it to be useful, you need to integrate it into your code.

First of all, you will need to install as a dependency in your project, by going to the folder where the package.json is at and running

`$ npm install fe-scss-commons@1.0.0 --save`

Now you will for sure make these abstracts available to your own component's code, and for that, you need to make it accessible, via your webpack configuration.

One way of having that done is via [sass-loader](https://github.com/webpack-contrib/sass-loader). Loaders are scripts (or packages of them) that webpack uses to interpret and process languages that are not JavaScript since JS is the only language it really understands.

If you're using sass-loader, while configuring it, you could pass the path to the package like this

{% gist https://gist.github.com/anfibiacreativa/935d806f47d17c404488f8885efed8bc %}

Which will then allow you to import all variables, with a simple import.

(Please go see the package structure in part III if you don't understand why I import `all_imports` directly ;) )

See how much we've cleaned up this file! Read the comments, to better understand!

{% gist https://gist.github.com/anfibiacreativa/79b9031ef8737c687556de5893fb4c1d %}

You should go back to part II, to see what that file looked like, before!

There is even more cleanup we can do, and I will explain that in a different post. But we have already removed a lot of unnecessary code and code repetition, moved the commons to a single location, reducing maintenance efforts, and outputting a lot less code.

Now in part V, the yummy beef, JavaScript commons, component loader, and scripts lazy loading ;)

Stay tuned!