Release – SGC: Gulp Toolchain V2.4

Release – SGC: Gulp Toolchain V2.4

Philipp Nowinski 07. August 2017 Releases

1 Comment // Reading Time: 5 min.

After the last release was a while ago, we are happy to announce the release of version 2.4 of our command-line tool SGC.  Beside some bugfixes, there are also some new features that helped us a lot to build the code base for the relaunch of our own website.

Under the hood – Dependency Management

With the new version we have also updated all node dependencies to the latest version. In addition, with the new version we are using Yarn for the first time as a supplement to NPM. Yarn is a package manager that comes from the React world and uses the NPM ecosystem. The integration into the existing code was relatively easy and especially the more intuitive CLI makes our work at bundlen much easier.

Better configuration options

The .sgc-config.json, the configuration wheel of the toolchain, has been cleaned up and extended with the new release. For the JavaScript and CSS pipeline, you can now configure whether the code should be minified and the compilation renamed to a .min file. This makes it a bit easier to find errors if something gets stuck. In the past we had the problem that Google-Font @import-Statements were not resolved in CSS (the uglify-task imports such code to save requests at runtime), because the CDN was not reachable for a short time (the bug is fixed \o/ by the way). By temporarily deactivating the minifier, the error could always be narrowed down quickly - all you have to do now is change a setting in the .sgc-config.json.

By the way, you don't have to pay attention to anything else when updating. The installation script will automatically recognize that you are using an older .sgc-config.json and add the missing entries automatically.

Better Linter

What our projects have probably profited most from in the last few months are the built-in JavaScript and Scss liners. With version 2.4 we switched from JsHint to EsLint in the JavaScript area and from scss-lint to Stylelint in the Scss area. Compared to the old tools, EsLint and Stylelint are much more powerful. Especially when it comes to extensibility, the tools are a dream. Configurations can be inherited and own rules can be added relatively easily. Certain things we couldn't check before are therefore a piece of cake. Our CGL, for example, provides that margin and padding declarations must always be the first statements in a style block, in exactly that order. StyleLint made it very easy to add this rule.
Thanks to its extensibility, you can also react quickly to any new situation. For example, we recently rewrote our entire module codebase from CommonJS modules to EcmaScript6 modules. A tool like EsLint, which screams at you from the console with every potentially unsightly line of code, is a real blessing - especially if you dare to venture into new realms like you were previously unaware of.

When installing the SGC, the tool will offer you to import our linter configurations, which we make publicly available in our GitLab. Of course you can also define your own rules, inherit and extend our configuration, or get another configuration from the internet.

Migration of existing installations

After a toolchain release, it is necessary to regularly update all existing projects. As many configurations change, it can quickly become agony. With the version 2.4. Also comes a small upgrade wizard that does this job. If you run the installation script in an existing installation, the script will detect this and ask you questions about how to proceed. So if you get the SGC over composer, just use a simple composer update sgalinski / sgc-core, followed by sgc-core / install.sh.

New commands

Two little helpers also made it into this release:

sgc releaseExtension --ext {extension_name}

If you are working with Composer, you are probably often in the situation of having to release changes to an extension as a new version. Choosing the correct version number and updating the correct files is theoretically easy, but in practice it always leads to errors. All too often we had the problem that e.g. for breaking-changes the major version number was not increased, bugfix releases were marked as feature releases, or the like. I myself often feel like I'm thinking about correctly adapting composer.json, but forget to do the same for ext_emconf.php.

The above mentioned task can help. The command starts a simple questionaire, which helps to classify the release correctly. After answering the questions, the correct version number is automatically set in both files. The result then only needs to be committed. A task that may seem simple, but has already saved me a lot of time and nerves.

sgc lighthouse

This task is currently still marked as 'experimental'. Especially if you have been working with progressive web apps lately, you will have stumbled across the tool Lighthouse from Google Chrome Engineers. Lighthouse is an analysis tool, similar to Google Pagespeed Insights, that lets your site run against a series of metrics and spits out a score and various optimization tips at the end. With the current Chrome version, Lighthouse has also become part of the Devtools.

At the moment this task does nothing else than chase your local instance through Lighthouse and write a report. Why integrate Lighthouse into the toolchain? Very simple: Lighthouse also allows you to write your own metrics and integrate them here. So this task is more a preview of what will come in future releases - so stay tuned ;-)

SGC Version X

The development of the SGC continues and we are far from finished. As always we are looking forward to feedback, feature requests and bug reports in our Bugtracker.

Get it while it's hot

Customers can now download the new release in our shop. If you have any questions about the SGC or our other products, please feel free to contact us at any time.


1 Comment

  • Stefan Galinski

    Stefan Galinski

    at 07.08.2017

    Awesome Release, Philipp! :-) Awesome Release, Philipp! :-)

    Drop files here
Drop files here