How did we get right here?
Whereas growing the second model of the Fellow browser extension, we realized that our present answer for managing the extension for our completely different environments — discovering and changing all related variables within the code earlier than importing packages — was attending to be an excessive amount of overhead. Within the first model of the extension, the one place the place we wanted a special worth for every surroundings was for the supply URL of an iframe, which was simple to modify out manually when wanted for native improvement, our staging surroundings, and manufacturing, as we might do it proper earlier than importing the extension to Chrome or Firefox.
As we added extra options to our extension, the checklist of locations we wanted to swap out URLs grew from one to 3. Nonetheless, we managed this manually as we solely needed to do it a couple of occasions. There have been a couple of builders engaged on the challenge, and all of us modified the URLs again to match our staging surroundings when committing code. Then earlier than importing our extension for approval, we swapped them out for manufacturing. We knew this answer was removed from best, however with solely three locations to swap out values and solely a handful of builders who wanted to recollect the place to swap them, it labored tremendous.
Then issues obtained extra difficult.
By the point the majority of the event was finished on the second giant iteration of the extension, there have been a dozen locations that we’d must swap out values. Moreover, it was not simply the surroundings URL that we needed to change — we additionally had a price to get the proper cookies, and one other that acted as a flag for performance that we wanted solely in our native environments. On high of that, with our extension now being a extra strong challenge that was actually taking off, it wasn’t onerous to think about that quickly much more builders would want to run the extension domestically to contribute to its improvement. The overhead of documenting all of the spots to swap values, and which values to swap them with, would have been onerous to take care of and prolonged to execute.
One half-measure would have been to tug all of the values that wanted to be swapped out of their information, and as an alternative export them from a world config file. This solves the difficulty of getting to doc (or keep in mind) all of the locations the place values must be swapped, however continues to be extra overhead than we’d like. We’d nonetheless must doc someplace what these values are for every surroundings, and producing the extension for a brand new surroundings would nonetheless contain modifying a file.
Then we discovered an answer that allowed us goal a selected surroundings for the extension with one command. Utilizing Gulp we will run a command like gulp — config STAGING and we’ve generated a listing with a model of our extension focusing on the staging surroundings, able to add.
How does it work?
In the long run, it’s actually only a fancy model of the config file answer. All of the values for an surroundings are positioned collectively in a config file, one file for every surroundings. These are named with the title of the surroundings like config.STAGING.json. Then, when the gulp command is run and the surroundings is specified, a model of the extension with the proper values for that surroundings is generated and dumped right into a specified folder.
The majority of this course of in outlined in a file referred to as gulpfile.js on the high stage of our extension listing. When gulp is run this file takes the suitable config file and dumps these values right into a file referred to as config.js. This file is the place the values are imported from elsewhere within the code. This config file and all the opposite extension information are copied to a separate folder, able to be uploaded.
So how does it try this? It defines 4 main capabilities and executes them so as:
- First it deletes any contents of the goal listing, to create space for the newly compiled one.
- Then it makes copies of all extension information, excluding config information, and provides them to the goal listing.
- Subsequent, it selects the proper config file, primarily based on the config flag handed when the command is run.
- Lastly, it writes the contents of the chosen json file to config.js within the goal listing. As soon as these 4 steps are full, all of the extension supply code and a config file with values for the goal surroundings are in a single listing, able to be uploaded!
What else can we do?
We’ve already prolonged this fundamental idea in a couple of methods. Along with creating config..json information for improvement, staging, and manufacturing, we will additionally create what I’ve been calling “on the fly configs”. These are config information to focus on not often used environments, like sandboxes, or environments with out constant URLs, just like the environments generated by our CI course of. In contrast to the opposite environments’ config information, these ones are usually not tracked in Git. As an alternative, they’re meant to be short-lived information which might be created when obligatory after which discarded.
One other complication that arose surrounds the config file for native improvement. Each developer at Fellow has a special URL for native improvement. If I have been to commit a config file with my URL in it, that wouldn’t be useful for the following developer seeking to run the extension to level at their native surroundings. As an alternative, the config file for native environments is just not tracked in Git, however a file referred to as config.template is. This template comprises json to be copied to a neighborhood surroundings config file and populated with the proper values for that developer’s native setup.
There are additionally different purposes for this than simply switching environments! For instance, we might add a flag like –browser and outline completely different config information for Chrome and Firefox. Presently in our extension, the browsers solely differ in a method: the trail to make use of to import pictures. We’re checking if we’re in Firefox earlier than including any picture in order that we will import it within the right method. As an alternative, we might outline the trail to a picture for Firefox in a single config file and to a picture for Chrome in one other, then use Gulp to generate the proper model of the extension for add.
These are only a few methods we’ve already expanded our use of Gulp, and there are numerous different prospects! It’s helped us enhance our improvement workflow and has decreased the quantity of issues we have to keep in mind. I hope the following pointers will enable you out too, and am excited to listen to about some other attention-grabbing use instances for Gulp with browser extension administration!
For a bigger instance (together with additional options equivalent to watching information for adjustments, and a pattern extension), check out this great post!