Convert existing Artillery YAML scripts to TypeScript or ESM JavaScript, auto-detecting the best output format, resolving YAML anchors by inlining, type-annotating exports, and verifying the output via tsc or node --check. Use when the user wants to migrate, rewrite, or translate Artillery load-test scripts from YAML to TS/JS for better IDE support, type checking, and composability.
80
100%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Risky
Do not use without reviewing
You are converting Artillery YAML test scripts to TypeScript or ESM JavaScript. The conversion is a 1:1 structural mapping — every YAML key maps directly to a JS export. Follow the steps below. Ask the user questions at each decision point marked with DECISION.
Glob for *.yml and *.yaml files in the project. Identify Artillery scripts by checking for config: and scenarios: as top-level keys. List the files found.
DECISION — If multiple Artillery YAML files exist, ask the user which to convert (or all).
DECISION — Determine whether to output TypeScript or ESM JavaScript:
tsconfig.json exists, or .ts files are present in test directories → output .ts with type imports.mjsBefore converting, scan each YAML file for anchors (&name), aliases (*name), and merge keys (<<:). These are YAML-specific features with no JS equivalent.
If found:
// WARNING: This file was converted from YAML that used anchors/merge keys. The shared references have been inlined as duplicated values. Review carefully — the conversion may not be accurate.For each Artillery YAML file, read it and convert to a JS/TS module. The mapping is purely structural — YAML values become JS object literals 1:1.
Each top-level YAML key becomes a named export: config → export const config = { ... }, scenarios → export const scenarios = [ ... ], before/after → export const before/after = { ... }. before and after have no dedicated Artillery types and are exported untyped.
Add type imports and annotations for config and scenarios:
import type { Config, Scenario } from "artillery";
export const config: Config = { ... };
export const scenarios: Scenario[] = [ ... ];If outputting .mjs, no type imports or annotations — just plain export const.
Write the new file next to the original YAML file, with the same base name but .ts or .mjs extension.
config:
target: https://api.example.com
phases:
- duration: 60
arrivalRate: 5
scenarios:
- name: "Browse products"
flow:
- get:
url: "/products"
headers:
Authorization: "Bearer {{ authToken }}"Becomes:
import type { Config, Scenario } from "artillery";
export const config: Config = {
target: "https://api.example.com",
phases: [{ duration: 60, arrivalRate: 5 }],
};
export const scenarios: Scenario[] = [
{
name: "Browse products",
flow: [{ get: { url: "/products", headers: { Authorization: "Bearer {{ authToken }}" } } }],
},
];Note: Artillery template expressions like {{ authToken }} stay as literal strings. The processor field (if present) is also kept as-is (string reference).
Try to verify the converted file:
npx tsc --noEmit <file> to type-check.mjs: run node --check <file> to syntax-checkTell the user:
npx artillery run ./path/to/new-file.ts (or .mjs)78a9dbe
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.