Named Configuration Sets

Configuration

{
  "preset": "balanced",
  "namedSets": {
    "checkout": {
      "match": ["src/checkout/**", "src/wallet/**"],
      "preset": "maximum",
      "options": { "DeadcodeLevel": "High" }
    },
    "marketing": {
      "match": ["src/marketing/**"],
      "preset": "standard"
    }
  }
}

Each set accepts match (an array of globs supporting **, *, ?, [a-z], and {a,b}), and any of preset, options, and countermeasures.

Resolution rules

• First match wins. A file matched by several sets gets the first listed one; write sets in priority order.
• Baseline survives. Effective options per file are the baseline options, then the set preset’s option block, then the set’s own options.
• Unmatched files are untouched. A file matching no set is protected with the baseline configuration, byte-for-byte the same as a build without namedSets.

How it runs

Each named set becomes its own API round. The JSON summary reports the grouping under namedSetGroups, the protection manifest spans every group, and when rounds return separate reports the summary carries buildIds for all of them. Because the plan gate prices each round on the options it actually carries, a set your plan cannot afford fails only its own group with the normal API error.

Where this sits among the granularity controls

• namedSets — different profiles per part of the app (this page).
• @virtualize markers — VM bytecode protection per function.
• protectMarkedComments — protect only marked regions of a file.
• VariableExclusion and ReservedStrings — pattern-scoped carve-outs inside any profile.

Frequently asked questions

Which set applies when a file matches more than one?

The first listed set wins for that file. Write sets in priority order, the way CSS rules or route tables are ordered. A file matching no set keeps the baseline configuration exactly.

How do a set's preset and options combine with the baseline?

Per matched file the effective options are the baseline options, then the set's preset option block if the set names one, then the set's own options. So a checkout set with preset maximum and DeadcodeLevel High keeps every baseline choice, adds everything maximum enables, and its own DeadcodeLevel wins last.

What happens if my plan does not cover a set's options?

Each named set runs as its own request, and the plan gate prices each request on the options it actually carries. A set your plan cannot afford fails its own group with the normal API error; the other groups are not affected.

Which version do I need?

jso-protector 0.4.0 or later, in both the CLI and the Node API protectFiles path. Earlier versions accept the key in configuration but do not act on it.