lazyloading-architecture (4 Part Series)
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.
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.
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
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
node_modules to your .gitignore!
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:
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:
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.
Email: (this IS public) firstname.lastname@example.org
If you're successful, you will see the following message in your terminal
Logged in as myusername on https://path-to-your-corporate-registry
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 )
$ 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.
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.
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 ;)
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 email@example.com --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.
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.