DEV Community: Alvis Tang

Presetter - Reuse your config files and build scripts over JS projects

Alvis Tang — Fri, 27 Aug 2021 10:14:22 +0000

Nowadays, as the JS/TS ecosystem continues to mature, developers are writing more and more build scripts and configuration files for their projects. How many times you've copied identical configs for babel, eslint, jest, typescript and the life cycle scripts in package.json?

For me, I've 40 common devDependencies, 24 scripts and 7 config files across my npm projects. Putting the need to copy and paste these things to bootstrap a new project aside, updating these tools across existing projects is just horrible pain. 🤦‍♂️

So I spent my spare time making presetter, a utility tool you'd love to use for easily and quickly reusing build scripts/configs across different npm projects. Now, instead of these countless devDependencies, build scripts, and config files, I can reduce them into just 2 devDependencies (or just 1 if you use npm 7+ which auto install peer dependencies automatically) and 1 config file (for presetter to determine which preset to use)!

😀 Sounds good. What is presetter and a preset then?

Presetter is a new open-source project that simplifies workflow for js/ts developers by providing a utility tool to enable us to store all common developmental configurations in one place, not a copy of those on each repo. This allows not only for the reuse of configurations but also reduces time spent on setup and maintaining the build systems across projects. Presetter is written in typescript but compatible with all js packages, backend, or frontend, as long as you use a package.json.

In a nutshell, presetter is a utility tool that set up and manage common devDependencies specified by a preset, which provides 3 types of common building configurations: devDependencies, build scripts, and config files. With presetter, you can replace many of your common devDependencies like eslint plugins etc and its config files and scripts into only two dev packages and a config file, namely presetter, your preset choice, and a .presetterrc file.

By pairing them up, you no longer need to spend hours on maintaining the build systems across projects. Instead, simply pick (and customise) a predefined preset either off-the-shelf from the community or an unpublished private package living in your git repository. What's more? You get version control on the build system for free due to the way how a preset is packaged. Life is much simpler since then!

😻 Wow. Tell me how to use it

To setup presetter for managing your build system, you can easily achieve it via the presetter use command:

npx presetter use <preset package name e.g. presetter-preset>

which would perform the following few things:

Install presetter and your choice of preset as devDependencies,
Patch the scripts field in your package.json to enable automatic bootstraping via the prepare life cycle script,
Bootstrap the preset by installing all the peerDependencies provided by the preset and create symlinks pointing to the generated config files on your project root, and
Create a .presetterrc file on the project root with the following content

{
  "preset": "<preset package name>"
}

After starting the project through bootstrapping, you have reached a point where it normally takes 5-10 minutes to duplicate all configuration settings from another repository. Now, you can achieve it by just ONE COMMAND!

To apply the preset scripts, you can execute a script by using the presetter run <script name> or shorthanded run <script name> command.

Using presenter-preset for example, when you invoke run build, presetter will merge the custom scripts defined in your package.json and the templated defined here, then invoke run-s clean build:*.

Tips

You can also use run <script name> as part of your life cycle scripts to make your build experience identical to what you have before. For example,

{
"scripts": {
  "build": "run build",
  "coverage": "run coverage",
  "lint": "run lint",
  "prepare": "presetter bootstrap && run prepare",
  "prepublishOnly": "run prepublishOnly",
  "release": "run release --",
  "test": "run test --",
  "watch": "run watch"
 }
}

👻 BUT. Can I customise it?

Short answer, SURE! You may be just 99% satisfied with the preset and want to change a little thing like turning on/off a lint rule, presetter just get you covered!

To do this, you just need to pass your customised config in the config field in .presetterrc.json. This config will be passed to the preset's configurator to achieve customisation. After adding your config, run npx presetter bootstrap again to regenerate the config files.

For example, to add DOM as a library in tsconfig.json provided by presetter-preset, simply add these lines in your presetterrc.json:

{
  "preset": "presetter-preset",
  "config": {
    "tsconfig": {
      "compilerOptions": {
        "lib": ["DOM"]
      }
    }
  }
}

Each preset can have its own set of customizable features. So check the preset's documentation for a full list of customisable elements.

🎩 Cool! What's the magic behind it?

Presetter may sound too good to be true. Now you don't need to copy and paste all the time. But you may wonder how does it work?

Well, it's actually pretty simple. Presetter basically does the following few things.

When you run presetter bootstrap, it

generates config files provided from the preset's template with your customisation applied and create symlinks on your project root, and
uses npm's arborist to install all peer dependencies defined in the preset's package.json, so that it works even with npm <7.

When you run presetter run <command>, it

merges your project's package.json with the script template provided by the preset and invoke the command.

That's basically all about how preset works. Now, let's see what kinds of presets are available and how to contribute one!

🐣 Alright. What presets can I try today?

A preset is a collection of common development configurations that can be applied to a project. It provides 3 groups of common building tools

devDependencies,
build scripts, and
config files

Today, we have 4 official presets for different kinds of projects:

presetter-preset-essentials: The starter kit for your typescript project, including settings for typescript, eslint, jest, prettier, standard-version and many others
presetter-preset-rollup: A collection of opinionated configurations for a building a code bundle via rollup.
presetter-preset-web: A preset for a modern web project
presetter-preset-react: A preset for a react project

Each preset is a single npm package. You can publish yours to share it with the community or just make it as a github repo without publishing it. Both works.

Another thing is that you can also contribute to the official presets. See CONTRIBUTING for all things related to preset's development and contribution!

👾 To Conclude...

Now you can stop worrying about managing devDependencies, scripts and config files. Presetter is a tool that reduces the complexity of your build system.

We all know that duplication of code is a bad thing, and there are many tools to eliminate it, but we don't have a tool for avoiding copying build configuration.

It's time to put the messy build configs aside. Try presetter today and visit the repository on Github for detailed documentation.

Don't forget to star or watch this repo if you like it! And don't forget to leave your comments below too. 👇

Did GitHub just start the Junior Developer as a Service era? Thoughts on GitHub Copilot

Alvis Tang — Thu, 22 Jul 2021 11:52:07 +0000

On Jun 29, the headline of many tech channels was the revelation of GitHub Copilot, an AI that writes code by the developer's command. This is not the first time an application of artificial intelligence has been used in software engineering, but it might be one of the most important milestones when considering its implications on how we learn to be an experienced developer.

Captain Dev, Copilot AI Reports for Duty

So, what is GitHub Copilot? Basically, Copilot is an AI that is delivered as a VS Code extension. GitHub promotes it as an revolutionary AI that is more than an auto-complete assistant. GitHub claims it can sense the intent of a programmer when he/she starts writing a new snippet and uses the context provided to synthesise code to match.

Under the hood, Copilot generates code using Codex, a variant of GPT-3 by OpenAI. When you write, it tries to understand the current state of your code and then generates relevant snippets. Given GPT-3 has been shown to be capable of generating multiple types of text in response to human prompts, it comes as no surprise that it can also write code.

The benefit, according to GitHub, is that Copilot can save developers time in building an application with new external components. From completing a database query to integrating a payment service, just write what you want to achieve in pain language and Copilot will write an example code for you.

The argument behind the claim, which is simple-seeming, is that the task of integrating a third-party component often requires only a few lines of code, but before developers can write those few lines of code, they have to research the documentation or read tutorials to learn how to use the new component they are integrating, which can take hours or days.

Junior Developer as a Service (JDaaS)?

Gosh! "Did Github just make a junior developer as a service (JDaaS) product!?", this is my first reaction when I read the intro of Copilot.

Who finds it difficult to read and understand documentation? Who wants answers from StackOverflow the most? Who spends most of their time doing just coding? Junior developers.

Experienced developers would know most of the time spent is actually not programming, but writing tests, docs and communicating with tons of stakeholders. Coding is only relatively a small portion of their time.

Now that Copilot is able to generate simple code by verbal commands, pretty much like a senior briefing a junior on what to do next in a project. I have to say this could be the beginning of JDaaS.

Copilot, where are we heading?

Now, with the arduous first step in creating any application - figuring out how the different components work - removed, how would this kind of new AI affect the ecosystem in tech?

I have an interesting view. It may end up holding tech back than the intended opposite. It is a threat to the tech industry. Not because they are powerful, but that I'm so afraid that we will lose the chance to learn to be experienced developers and hence hindering the potential of our future technology development.

The reason is that while Copilot is designed to help developers write code more quickly, in doing so, it removes the good part of it - the opportunity for us to experience the pain and the frustration, and the fun and the feeling of achieving upon figuring a difficult task. Everything Copilot removed is essential for a junior developer to learn to be an experienced developer.

With this development, companies will be more reluctant to hire junior developers and train them to be the next generation developers too. In the US, even a junior web developer can cost you $80,000 a year. Knowing an AI can do most of the tasks a junior can do, what would you do as an employer?

Copilot is a genius application, but it could be the thing that makes junior developers less likely to be hired and become experienced leaders one day.

Brace, Brace, Brace

As a tech leader, I am glad that artificial intelligence has bought us all sorts of new tools to allow us to do our work more efficiently. For example, when someone wants to find out something about their medical condition, you can just say it to Google Assistant and you would get pretty much professional-grade answers like a real doctor. The benefits of AI are just undeniable.

But sometimes I feel like the advance of AI, by achieving higher efficiency, takes away something that we actually enjoy doing or at least something that we need to go through it. Figuring things out yourself and making mistakes is the necessary process for learning to be an expert.

Now, the impact of AI on the tech industry has never been this close. Like other industries, we also have to start accessing its impact on us and adapt. In the long run, I hope that AI will make junior developers more experienced and not less valued in the industry. We need a healthy supply of talents.

To ensure that we have people who can fly planes in the future, we need first officers, not captains!

Where to find me:
github | linkedin