> ## Content Index
> Fetch the complete content index at: https://dsl-consultancy.ghost.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# Setting up
- URL: https://dsl-consultancy.ghost.io/setting-up/
- Published: 2026-08-28T07:55:13.000Z
- Updated: 2026-09-24T08:28:39.000Z
- Author: Meinte Boersma

💡

This is post 04 in my blog series on MyFPL — see [the index/table of contents](https://codeberg.org/dslmeinte/my-fpl/src/branch/main/blogs/index.adoc?ref=dsl-consultancy.ghost.io).  
  
The code in this and previous blog posts can also be found [here, on Codeberg](https://codeberg.org/dslmeinte/my-fpl?ref=dsl-consultancy.ghost.io). Check out the repo at the commit marked “blog 04”.

It’s about time we start to do some actual coding! The first section below explains what tech stack we’ll be using to develop MyFPL with. The second section explains how to set up a development environment for (and in) that.

## The tech stack

I’ve chosen a tech stack with the following technologies and frameworks:

- TypeScript as a programming language. JavaScript is arguably the “assembly language of the web”, and a bit of a “footgun”, at that. TypeScript is a pretty good way “to engage the safety catch” of JavaScript. Virtually every time I’ve worked on a code base that used pure JavaScript instead of TypeScript, I’ve come to regret that choice — whether that choice was mine or not.
- Node.js as a JavaScript execution engine. There are other suitable runtimes – such as Deno and `bun.sh` – but their upsides don’t outweigh Node.js’ ubiquity in the context of this project. Most of the code base we’re going to be writing is essentially “runtime-agnostic” apart for assuming an ECMAScript-compliant standard library.  
Node.js comes with NPM, a package and dependencies management system. Even though NPM comes with plenty of downsides, it has the benefit that it’s suitable for web- and non-web JavaScript code bases. Since a while, its support for multi-package projects is decent enough.
- [LionWeb](https://lionweb.io/?ref=dsl-consultancy.ghost.io) – and specifically its [TypeScript implementation](https://github.com/LionWeb-io/lionweb-typescript?ref=dsl-consultancy.ghost.io) – as the framework for the underlying AST infrastructure. I’m one of the founding members of the LionWeb initiative, so it’s no surprise I’ll be using that.
- React as a web UI framework.
- MobX as a state management library. This library seems to have survived for some time already alongside other libraries with similar purposes, but often wildly-differing philosophies, such as Redux, React hooks, Signals, etc.  
I’m particularly pleased about that since MobX was created a desk away from me, as part as a project I was working on, based on the principle of “The UI should be a pure function of application state.” A fancy acronym for that principle is **TFRP**: Transparent Functional Reactive Programming.
- Some additional dependencies, such as `nanoid` for generating (sufficiently-)unique IDs.
- `eslint` to check the code stylistically, and for code smells. This might be a little overkill, but it’s nice to have some additional safeguards in place.
- Some POSIX-compliant CLI (shell or bash).
- Git as versioning system. (Theoretically optional, but too practical not to use it.)

## Setting up the development environment

For the implementation of MyFPL, we have to set up a suitable development environment. To do that, clone [the MyFPL repository](https://codeberg.org/dslmeinte/my-fpl?ref=dsl-consultancy.ghost.io) as follows:

```
git clone https://codeberg.org/dslmeinte/my-fpl.git
```

This should leave you on the `HEAD` commit of the `main` branch. From here, run the following on the CLI, with each line being a separate command:

```
npm run clean (1)
npm i (2)
cd packages
cd build (3)
npm run generate
cd ../my-fpl (4)
npm run build
cd ../.. (5)
npm run lint
```

1. Clean all non-committed files — specifically `dist/` and `node_modules/` directories that might have stale content. This is hardly ever necessary.
2. Install all NPM dependencies. `npm i` is shorthand for `npm install`. This is not always necessary, unless a `package.json` lists more (or other) dependencies than it did before.
3. In the `build` package, run the code generation.
4. In the `my-fpl` package, build the sources.
5. Lint all source code.

The shell script `make.sh` does exactly the same — run that as:

```
./make.sh
```

For more information about how this repository is organized, how to do development inside it, and how it “time travels”: see the [README.md](https://codeberg.org/dslmeinte/my-fpl/src/branch/main/README.md?ref=dsl-consultancy.ghost.io).

You also could set up a development environment from scratch, as long as you end up with the same folder and file structure. But honestly, just clone [the MyFPL repository](https://codeberg.org/dslmeinte/my-fpl?ref=dsl-consultancy.ghost.io), and get coding as quickly as possible.

💡

In this blog post, we’ve set up the development environment that I’ll be using to implement MyFPL. In the next blog post, I’ll explain how we’re going to organization MyFPL’s structure aspect.

© 2026 Meinte Boersma (DSL Consultancy)