SimpleWebUtils
ENKO

Document Workflow

Format and minify code safely before deployment

A practical parser-first workflow for formatting or minifying CSS, HTML, JavaScript, JSON, GraphQL, YAML, XML, and Go without confusing smaller output with verified behavior.

Written and tested by Published: Reviewed:

How this workflow was checked

The review loaded the unmodified “Minify a JavaScript release file without breaking URL and regex tokens” sample into Code Format Workbench. We exercised the path from “Identify the source grammar and its real destination” to “Compare exact output, size, and executable behavior”, checked the displayed or downloaded result against the example, and separately examined “Deleting the source after getting a smaller file” and “Treating HTML recovery as XML validation”.

The Terser pass reduced measured bytes while preserving the license comment, URL, escaped regex, template literal, and exported behavior with identifier mangling disabled.

Open Code Format Workbench | CSS, HTML, JavaScript, and More

Problem

Teams often paste code into a generic formatter, accept any non-empty output, and commit it as if whitespace were always insignificant. That can round large JSON identifiers, erase comments required by licenses or operations, recover malformed HTML into a different DOM, minify an ES module as a classic script, change CSS cascade behavior through restructuring, or format invalid XML by inventing missing structure. The objective is to select an operation the language actually supports, fail closed on malformed structured input, retain a reproducible source and configuration, and prove the generated artifact in the exact environment that consumes it.

When to use this

  • A CSS, HTML, JavaScript, JSON, GraphQL, YAML, XML, or Go file must be normalized before code review or checked against a team formatter.
  • A front-end asset or JSON payload is being minified for a release and its byte reduction must be measured without losing the original.
  • A copied configuration, API fixture, query, or XML document may contain parser errors, duplicate keys, large numbers, or misleading recovery behavior.
  • A local browser result differs from Prettier, Terser, CSSO, gofmt, a CI build, or a production parser and the exact configuration must be isolated.

Steps

  1. Step 1

    Identify the source grammar and its real destination

    Record the language, file role, parser or runtime version, source type, schema, and downstream build step. Distinguish HTML from XML, strict JSON from JSONC, YAML configuration from an application schema, and a JavaScript classic script from an ES module. Choose format, minify, or CSS syntax check only when that operation matches the goal; do not use formatting as a substitute for compilation, schema validation, rendering, or tests.

  2. Step 2

    Preserve the original and remove sensitive material

    Keep the source in version control or a separate fixture and work on a focused fragment. Remove credentials, private URLs, customer values, tokens, and proprietary content before it can enter clipboard history, screenshots, browser extensions, crash reports, or downloaded files. Record a checksum or diff base when exact byte comparison matters.

  3. Step 3

    Run the parser-specific task with explicit settings

    In Code Format Workbench choose the language and available operation. Set indentation and print width for formatting. For JavaScript choose classic script or ES module and the intended style options. Run manually and stop on parser errors, NUL input, character or byte limits, malformed JSON, duplicate YAML keys, mismatched XML elements, invalid GraphQL, or gofmt syntax failure rather than editing source until a generic tool returns output.

  4. Step 4

    Review diagnostics and format-specific invariants

    For CSS, remember that syntax-only validation does not prove browser support or cascade behavior. For HTML, inspect the recovered DOM and visible inline whitespace. For JavaScript, retain license comments and confirm the source type. For JSON, compare large integer, decimal, exponent, escape, and duplicate-key tokens. For YAML, preserve comments and confirm schema rules. For XML, require well-formedness before schema validation. For Go, treat gofmt as layout, not compilation.

  5. Step 5

    Compare exact output, size, and executable behavior

    Save the displayed output and settings, then compare a semantic diff against the original. Record input bytes, output bytes, changed status, and compression savings without assuming that smaller means correct. Run the candidate through the actual browser and accessibility checks, JavaScript build and tests, CSS visual regression, HTML templates, JSON consumer, GraphQL schema validation, YAML loader, XML DTD or XSD policy, or Go compiler as applicable.

  6. Step 6

    Automate the approved formatter and rollback path

    Once the destination result is verified, pin formatter and minifier versions and configuration in the repository, add representative edge-case fixtures, and make CI compare or regenerate artifacts deterministically. Keep source maps, license handling, source files, and a rollback condition. Do not make an unreviewed browser download the only copy of a production asset.

Example

Minify a JavaScript release file without breaking URL and regex tokens

Input

A classic script containing a /*! license */ comment, https://example.com/a//b string, /a\/b/ regex, template literal, and tests for the exported behavior

Output

Terser output with one safe compression pass, identifier mangling disabled, the /*! comment and literal tokens preserved, measured byte savings, and passing build, unit, browser, source-map, and license checks

Common mistakes

Deleting the source after getting a smaller file

A minified artifact is difficult to review and may omit source maps or comments. Keep the canonical source, reproducible configuration, and a verified build path.

Using regex to minify structured languages

Regex substitutions can corrupt strings, URLs, regex literals, calc expressions, preformatted HTML, escapes, and nested syntax. Use a parser that understands the selected grammar.

Treating HTML recovery as XML validation

HTML parsers can repair malformed structure, while XML requires correctly nested elements. Inspect the HTML DOM and require a dedicated well-formedness check for XML.

Changing JSON values during whitespace removal

Parsing into JavaScript numbers can round large integers, and serializing can normalize token spellings or resolve duplicate keys. Preserve exact tokens when the job is only minification.

Equating a formatter with the complete toolchain

Prettier, CSSO, Terser, an XML parser, and gofmt each cover a narrow contract. They do not replace schemas, compilers, type checks, browsers, accessibility reviews, security policies, or application tests.

FAQ

Should generated minified files be committed?

Commit them only when the deployment or distribution model requires checked-in artifacts. Otherwise build them reproducibly in CI. In both cases pin versions, keep source and configuration, verify licenses and source maps, and make artifact drift detectable.

Can formatting change behavior?

Usually a correct formatter preserves language semantics, but parser recovery, HTML whitespace, JavaScript source type, CSS restructuring, comments consumed by tools, and destination-specific rules can still change observable behavior. Verify in the real consumer.

Why keep identifier mangling disabled in the browser minifier?

Disabling mangling makes a one-off result easier to review and avoids assumptions about reflection or external name contracts. A production build can enable mangling with its complete dependency graph, property policy, source maps, and tests.

Is valid YAML or GraphQL syntax enough for deployment?

No. YAML still needs the target application's schema and custom-tag policy. GraphQL still needs schema validation, authorization, variable checks, resolver behavior, and cost controls. Syntax is only the first gate.

What evidence should be attached to a formatting or minification change?

Keep source and destination identifiers, tool and version, exact settings, input and output byte counts, semantic diff, parser diagnostics, edge-case fixtures, destination build and test results, visual or accessibility evidence where relevant, license and source-map checks, and a rollback condition.