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.
100
100%
Does it follow best practices?
Impact
Pending
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.