Migration of JavaScript files to TypeScript

[Simon1375]

TypeScript Migration Plan

This document describes the planned migration of the BenchExec React
frontend from JavaScript to TypeScript.
The goal is to ensure a reproducible, structured, and well-documented
migration process.

---

1. Migration Strategy

The migration follows a sudden migration strategy.

This means that the project is migrated to TypeScript as a whole,
instead of gradually introducing TypeScript while keeping JavaScript
as the primary language.

Rationale

The sudden strategy was chosen for the following reasons:

• The project has a clearly separated frontend codebase.
• Introducing mixed JavaScript and TypeScript code long-term would
  increase maintenance complexity.
• A clean TypeScript-only codebase is the desired end state.
• The migration is performed in a controlled environment and not during
  active feature development.

Although the strategy is classified as sudden, a short technical
transition phase is allowed using allowJs in the TypeScript
configuration to enable incremental conversion of files.

---

2. Migration Steps

The migration is structured into the following steps:

1. Define migration strategy
2. Check library support for TypeScript
3. Add and configure TypeScript (tsconfig.json)
4. Integrate TypeScript into the build process
5. Configure linting for TypeScript
6. Adapt development environment and scripts
7. (Optional) Generate API type definitions
8. (Optional) Use migration tools
9. Migrate source files, starting with core modules

Each step is documented by one or more dedicated Git commits.

---

3. Commit Structure

To ensure traceability, each migration step is represented by
structured commits.

Step Commits

Each migration step starts with a commit of the form:

chore: step <n> <short description>

---

File Migration Commits

When migrating individual files or modules using automated tools,
the following commit sequence is used:

1. Rename File
   rename: <file>.js to <file>.ts/.tsx

2. Tool output
   tool: convert <file>

3. Minimal fixes
   fix: make <file> compile

   (Only required if the automated conversion does not compile.)

4. Manual cleanup
   refactor: cleanup <file>

This separation makes it explicit which changes were automated and
which were manual improvements.

---

4. Migration Order

The migration of source files follows a bottom-up approach:

1. Utility and helper modules
2. Common components
3. Feature-specific components

This order minimizes cascading type errors and simplifies refactoring.

---

5. Goals and Non-Goals

Goals

• Fully typed TypeScript codebase
• Strict type checking
• Clear distinction between automated and manual changes
• Reproducible migration process

Non-Goals

• Functional changes to application behavior
• Refactoring unrelated to type safety
• Introduction of new features during migration

---

Step 6: Development Environment

No specific IDE or editor is required for this project.
TypeScript support is provided via the TypeScript compiler and ESLint,
which are executed through npm scripts.

Developers are expected to use the following commands:

• npm run typecheck – perform standalone TypeScript type checking
• npm run lint – check code style and potential issues
• npm run lint:fix – automatically fix lint and formatting issues

This ensures a consistent development workflow independent of the
editor or IDE used.

Step 7: API Type Generation (N/A)

The project does not use generated API clients (e.g., OpenAPI/Swagger, GraphQL codegen).
Therefore, no API type generation step was required.

Step 8: Use of Migration Tools

Due to the size of the codebase, automated tools were used to support
the migration from JavaScript to TypeScript.

ChatGPT was used as an auxiliary tool to perform initial conversions
of JavaScript files to TypeScript. The tool-generated output was not
used directly without review.

Each automated conversion was followed by:

1. A commit containing only the tool-generated output
2. A commit fixing TypeScript compilation errors
3. A commit performing manual cleanup and refactoring

This approach ensures a clear separation between automated and manual
changes and improves the reproducibility of the migration process.

Step 9: Migration Checklist

Order (bottom-up):

• src/utils/ (utils.js, filters.js, stats.js, plot.js)
• src/workers/ (workerDirector.js)
• src/components/ (leaf components → central components)
  • src/components/FilterBox/
  • src/components/Table/
• Entry points (src/App.js, src/index.js)
• Tests (src/tests/**, src/App.test.js)

[PhilippWendler]

I found some bugs! But in the old code, and they are fixed here. ;-)

• For a numerical filter with a slider, moving the slider would live-update the numbers in the input fields below only on the first use of the slider. On further slider moves the numbers would update only after releasing the mouse click on the slider. Now the input fields always update immediately when using the slider.
• In the same place, the behavior for very small numbers was also improved. Using the up/down buttons on the input field can still introduce unwanted scientific notation, but using the slider reverts it to our preferred formatting. Previously the slider would keep scientific notation if present before. Furthermore, the value in the URL is now always correct and never scientific notation, even if the input field currently shows scientific notation.
• When using the up/down buttons on the input field of a numeric filter, previously the shown values did not swap places when incrementing the min beyond max, but for applying the filter the values were swapped. Now the shown values also swap places, making what is shown consistent with what is applied for filtering.

I think these bugs were not directly found due to type checking, but more indirectly due to the refactoring that was triggered by the fact that type annotations showed how inconsistent the previous solution was, but still nice. :-)

Apart from this I didn't find any differences, neither with the test table of npm run start, nor with the example table, nor with a table of some of my benchmark results with 50k results.

In summary, a nice improvement that hopefully helps us for being able to better develop the application further in the coming years. 🚀