1 Comment // Reading Time: 6 min.
After a little over one and a half years, our command line tool SGC has achieved its next milestone today: We are publishing the long-awaited version 3!
The jump up to the version number 3 is a major update in every way. In addition to the usual bugfixes and small new features, we restructured the entire code base and rewrote most of it. On one hand, this enabled us to reduce our dependencies and structure them more clearly, but most importantly, the new architecture allows us to implement new features much more easily and expand the toolchain continuously. Let's get into more detail about what is new in the v3 release.
New Core – No More Gulp
So far, Gulp has been at the heart of the SGC. Looking at the software as an orchestra lets you distribute the different tasks to the various instruments. Each instrument plays its own, very specific role with Gulp acting as the conductor who gives each task its cue in accordance with the user's score. Gulp was very good at this job.
But, as time passed, this conductor got more and more in our way instead of supporting us. The reason for that wasn't him being incomepetent or becoming senile with his rising age. Instead, over time it became more and more clear what exactly we wanted to cover by our tool and what our workflow's strengths and weaknesses were. The project kept growing and maturing, as did our expectations of how which parts should function. As the tool's authors, we became more and more a second conductor, which led to Gulp and us constantly treading on each other's toes.
Less Code, Better Code, Faster Iterations
A Cold Wind in Dependency-Hell
A very pleasant side effect of the rewrite is the fact that we now have a vastly improved oversight of our dependency tree. It is commonly known that
npm install downloads half of the internet. Thanks to better control of the core, there now is one less level that installs dependencies because we can now use libraries such as libsass or imagemin directly. The abstraction from the Gulp plug-in is now omitted and thus some of the dependency tree's branches have been cut off.
Another side effect that gets noticed thanks to the gained control over the code is the presentation of the console output. So far, the SGC's output has been a mixture produced by various libraries. String with a timestamp at the beginning? - Sure, gulp.util! No timestamp, but a formatted error message? - Ah, Stylelint! Again, no timestamp, but instead the same error message twice in varying format (WTF?) - Hello ESLint.
During my daily work, I look at this output very often. Especially when it's your job to write code to make things look better than they did before, it can be very frustrating if the tool that's supposed to support you is designed this inconsistently. Not to mention the fact that inconsistently designed code makes it harder for you to mentally parse it and to grasp the important information. With every output looking differently, I have to remember many more patterns than what would actually be necessary.
With the SGC 3 we deliver our own logging module. All output gets processed by it, giving it a consistent style. In general, we used this opportunity and put a bit more love into the console output. Colored highlighting and indentations make it easier for you to read out the important bits. The output of both linters follows the same styling and error messages are very clearly distinguishable now.
With the new version we also implemented desktop push notifications for the first time. Especially while using the watcher, it often happened to me that I saved erroneous code that could not be compiled. Usually this made me waste at least a few minutes debugging before I took a look at the console. Since version 3, the SGC now lets you know of any occurring errors via a desktop push notification. This way, you won't miss errors as easily anymore. By the way, the notifications also appear for linting errors so those can't be missed during development anymore. In fact, these messages led to almost no more formally erroneous frontend code being committed internally at our company. The reason for this is simple: a message popping up every time you save a file can quickly get very annoying ¯ \_(ツ)_/¯.
Additionally, we optimized the settings for image optimization and compression of minimized files. Thanks to these improvements, we were already able to measure a significant improvement in performance on our own website.
On our product page, you can see all features of the SGC in a short overview and choose the right version for you.
Are you using an sgc-scripts folder to extend the SGC through your own commands? If so, this feature could be useful for you. We are using an sgc-scripts folder that is versioned itself and is shared between several projects. Within this folder you can now save a .sgc-config.json file that is merged with the existing file during execution. This lets you write a default configuration very comfortably. The configuration file of the actual project afterwards only needs to overwrite a few settings.
The best is yet to come: with version 3 of the SGC we are publishing the entire source code as OpenSource for the first time. As of today, the repository is publicly available in our GitLab instance. This way, you can also install the tool very easily through Composer. We will keep the existing licensing model but of course it is open for you to take a glance at the product before your purchase.
Don't hesitate and just install and explore the toolchain to find out if its workflow suits your projects. Of course, feedback, bug reports and even merge requests are always welcome in our Bugtracker.
Get it while it's hot
All customers can download the new release from our shop from now on. If you have any questions about the SGC or any of our other products, you are welcome to get in contact with us.