Fresh cell therapy for JavaScript

JavaScript, based on ES6+ with npm, Babel, and Webpack, is the standard for state-of-the-art web development. It makes it possible, together with the development environment, IntelliJ, to work efficiently. However, how can one bring 265,000 lines of JavaScript code up to date, switch to a different development environment, and develop new features, all at the same time? A development team at BSI shows us how it is done.

The work environment before the switch to IntelliJ

The starting point

Eclipse Scout, the open source framework developed by BSI, is the foundation for our products, such as the BSI CRM, or BSI Studio, the marketing automation solution. Five years ago, the old UI layer was migrated from Swing to HTML, and thus Scout became a web framework. The JavaScript code from then corresponds to the EcmaScript 5.1 standard that was current at the time; until now, we have been using Eclipse IDE for development work.

With the recent CRM Release Ocean, we wanted to migrate the entire JavaScript codebase to ES6+, change the development environment from Eclipse to IntelliJ, and replace various proprietary build tools with npm and Webpack. This conversion had to occur in parallel with the development of new features, both in Eclipse Scout as well as in our products, which means that the migration was not to be in the developers’ way. Therefore, the switch had to take place automatically to a large degree.

Process

The migration team included five BSI developers. Initially, this team created a prototype of the Eclipse Scout framework based on ES6+ and a simple application that was based on the migrated framework. This prototype uses state-of-the-art ES6+ syntax and language constructs such as import, class, and extends. Unlike in the past, the build is no longer done with BSI-specific tools, but with npm, Webpack, and Babel. The prototype defines what the migrated source code looks like, which language features are used, and how the framework is divided into ES6 modules. In this context, it was important to give the developers using IntelliJ the best possible support, for example, by completing code for JavaScript classes. This requirement had a big impact on how the ES6 modules and exports were laid out.

1. Managing dependencies with JavaScript

Therefore, ES6 modules and dependency management involve a great deal of conceptual work. How to divide the code into modules? Where to host the modules? Which modules must be in the public npm registry, and which ones internally only in Artifactory? Which versioning scheme should we use with npm? How to deal with snapshots and locally checked-out modules with multiple dependencies? This last point, in particular, was very hard to find a solution for, and it ultimately resulted in the team deciding in favor of using pnpm.

Once we had defined the migration goal, the team was able to tackle the next step: the migrator.

2. Code migration at the touch of a button

The migrator is a Java program that updates our existing source code automatically and without any substantial manual intervention following the conventions defined in the prototype. Various tasks transform the code and perform jobs such as inserting imports or using the keywords class and extends. Not only does the program update the framework code, but also the project code, which is based on the framework – an important feature for our customer projects.

«We developed the migrator iteratively: During the development, we ran the migration continuously and built and deployed the migrated code, ensuring that we would identify errors quickly, which the developers could then correct.»

André WegmüllerSoftware Engineer at BSI

Problems occurred particularly in those areas where developers had departed from established patterns in the old code. We then analyzed these spots on a case-by-case basis. Depending on the situation, we either corrected and standardized the old code or adapted a migrator task in a way that allowed us to process the relevant code spots.

3. From Eclipse to IntelliJ

In the meantime, part of the team focused on the conversion in the development environment: away from Eclipse and on to IntelliJ. For Eclipse Scout, BSI had developed its own Eclipse plug-ins to be able to work more efficiently. We now had to migrate these plug-ins. Gradually, configuration files and launch configurations were made available for IntelliJ. The team continuously created documentation on topics such as installation, getting started, or key shortcuts to make the switch to IntelliJ as easy as possible. All developers were able to use the workspace with either Eclipse or IntelliJ at any time. To keep maintenance costs low, we will be maintaining only the IntelliJ configurations going forward.

4. Weekend migration

After four months, the critical date came closer. In consultation with all members of the 35-person product development team, we agreed on a push stop for all GIT repositories for the duration of one weekend. Right at the beginning of the weekend, the migrator started and updated the entire source code. All changes were pushed to GIT, the builds were started, and the built applications were newly deployed and tested on the test systems. The migration team made a few final changes to the IntelliJ package – but then everything was done. On Monday morning, every developer was able to start up IntelliJ and start the week off with the new JavaScript code.

The migration team

The conclusion

It is only natural that there were some minor problems in the first few days that we needed to resolve. In addition, the switch to IntelliJ involves a big adjustment and a learning curve for seasoned Eclipse users.

«Overall, however, we are happy about the new code, the great IDE support for Web technologies, and the tools we have with the state-of-the-art tool stack.»

André Wegmüller

Babel is a particularly valuable tool for our JavaScript developers. The transpiler ensures that developers can use current Ecma language features without having to worry about older browsers because Babel generates code during the build with Webpack that can run on these browsers. The conversion was a success. With new code and IntelliJ, we are well equipped to more strongly rely on JavaScript for development work in the future and maintain a robust, maintenance-friendly codebase in spite of large amounts of code.

The work environment after the switch to IntelliJ
Date