Migration to Atom Community

[idleberg]

Today, I've transfered buildium –a fork of the popular build package` to the Atom Community. In the following, I'd like to describe my motivation for doing so, what I've worked on in the past and what lies ahead.

Motivation

It might surprise you to hear, that I have never used build/buildium for anything other than testing the build providers I have published. Like many of my other Atom packages, my motivation is rooted in my involvement with NSIS, a scripting language to write Windows installers.

With build installed, I noticed that it slowed down my startup time and sent user data to GitHub. These were the two main issues I wanted to change.

Past Changes

User Tracking

The built-in user tracking of the build package isn't compliant with the GDPR, the CCPA, and similar regulations. From the GDPR:

1. Consent must be freely given
2. Consent must be specific
3. Consent must be informed
4. Consent must be unambiguous

The build package tied its consent to the telemetry packages, so it violates just about any of those points. While I'm not opposed to user tracking per se, I decided to remove user tracking altogether.

Activation Time

Activation was deferred by simply using the core:loaded-shell-environment hook. It is my assumption that activation can be further improved, e.g. by using modern UI libraries, service providers, tree-shaking and dynamic imports. There are existing issues for some of these potential improvements.

Switch to xterm

build uses an 6 year-old version of tern.js. Existing PRs to switch to xterm have never been merged. And while xterm@2.9.2 lags two major versions behind the latest release, the switch has been an important first step.

Config Files

buildium uses cosmicconfig to parse its config files. This allowed stripping some code in favour of a well-established third-party library.

Visual Integration

The UI of build, didn't integrate well with Atom's interface or third party themes. buildium tries to follow the style-guide in all of its visual elements.

Future Changes

I've outlined my vision for buildium in the issues section, most notably the following:

• Convert to TypeScript
• Use with terminal service provider
• Write new tests
• Linter v2 integration

If you want to help making buildium future proof, feel invited to discuss changes, make feature requests or submit PRs!

[hovsater]

@idleberg thank you for this! I'll see if I can pick up some of the issues in my spare time.