Live Development of a Bower Component
You created a Bower component to make your frontend code reusable. You release new updates and you are happy.
You also have Web software project. You release new updates and you are happy.
At some point, you would like to develop your Bower component within the Web project, and release both of them independently and only after the feature is complete.
§tl;dr
bower link
is a powerful but not well advertised feature. I will explain how to use it as part of a real project architecture.
§Project Architecture
Here is a sample Bower component architecture:
1 |
|
A simple package descriptor with a JavaScript component, ready to use. We manage this as an independant codebase, somewhere on our computer.
On the other hand, here is how a regular project could be handled, in another place of our computer:
1 |
|
Two Bower components are installed through the bower install
command, my-bower-package
and semicolon.js
. Because we all need a rocket stellar modern JavaScript framework to brew some coffee.
These dependencies are managed as following thanks to the bower.json
file:
1 |
|
This is neat but it also means we rely on remote repositories to receive new updates. The only way to receive updates in my-bower-component
is to bump a version upper to 1.33.7
(like 1.33.8
, 1.33.10
or more). It is suitable for a production use, but what if we want to use a local development version of my-bower-component
at the same time?
§Enters Bower Link
The first time I’ve read the bower link --help
documentation, I found the explaination confusing. What is a project? What is some other package?
Well, here it goes.
In our my-bower-component
workspace, bower link
will register the package as available to be linked. But it will have no other effect anywhere else, yet:
1 |
|
Back to our Web project directory, containing my-bower-component
in the dependencies
part of the bower.json
, we will then type:
1 |
|
Now, your project will benefit from every file change of the my-bower-component
component. Exactly what we wanted.
The project tree structure is now the following:
1 |
|
It simply symlinked the component for us. You may have done that by hand but it provides some extra sugar: the next time you do bower update
, it will wash the symlink away and any version complying with the semver spec as defined in your bower.json
file. Back to the normal.
This is particularly useful for the following use cases:
- prototyping a Bower component before releasing it in the wild (you can link it even if it’s not yet available in the bower registry)
- testing a new feature in a live project
- checking why a component is failing to work as expected despite its unit and functional tests are fine
Have you found another use case? You disagree with this way of doing? Share your insight in the comments below :-)