Static Markdown imports fail in Workflow SDK bundles

[MaxSvargal]

Summary

withWorkflow() runs its own esbuild pipeline for discovered steps and workflows. That pipeline does not inherit the outer Next/Turbopack raw loader, so a workflow-reachable static Markdown import fails unless the application falls back to a runtime node:fs read. Runtime filesystem access is unavailable in the workflow VM sandbox.

Minimal reproduction

// app/workflow.ts
"use workflow"

import instructions from "./instructions.md"

export async function example() {
  return instructions
}

# Bundled instruction

// next.config.ts
import { withWorkflow } from "@workflow/next"

export default withWorkflow({
  turbopack: { rules: { "*.md": [{ type: "raw" }] } },
})

next build --turbopack accepts the outer raw module but Workflow SDK's step and interim workflow esbuild contexts lack a .md text loader.

import ... with { type: "text" } is not a viable workaround in this path: the preceding SWC transform removes the attribute before esbuild resolves the Markdown module.

Expected behavior

Markdown modules should default-export their build-time string content in both step and workflow bundles. In next dev, editing an imported Markdown prompt—including one supplied by a workspace package—should rebuild the Workflow artifact without restarting the server.

Proposed fix

Add esbuild loader: { ".md": "text" } support to the relevant builder contexts and make the Next development watcher include Markdown dependencies under the configured project root. I will follow with a draft PR containing regression coverage for step, workflow, production-build, and development-watch paths.