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 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 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 )

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. 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

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!

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!