Description
Third-party consumers of the UMD build (SFIr) need to dynamically discover rule configuration capabilities. The source code already has the ConfigurableOption interface and rules already declare their configurableOptions, but this metadata doesn't survive into the published UMD bundle.
Current behavior
getRules() returns rule instances with isConfigurable: true/false
configurableOptions is not accessible on rule instances in the UMD build
- Consumers must hardcode which rules accept
expression vs threshold and their defaults
Expected behavior
getRules() returns rule instances where configurableOptions is preserved and accessible
- Each
ConfigurableOption includes name, type, description, and defaultValue
- This allows consumers to dynamically build configuration UIs without hardcoding rule-specific knowledge
Example of what consumers could do
const rules = lightningflowscanner.getRules();
for (const rule of rules) {
if (rule.isConfigurable && rule.configurableOptions) {
for (const opt of rule.configurableOptions) {
console.log(`${rule.name}: ${opt.name} (${opt.type}), default: ${opt.defaultValue}`);
// APIVersion: expression (expression), default: ">= 50"
// CyclomaticComplexity: threshold (number), default: 25
// FlowName: expression (expression), default: "[A-Za-z0-9]+_[A-Za-z0-9]+"
}
}
}
Why this matters
- Eliminates manual maintenance for downstream consumers when new configurable rules are added
- The code already exists —
ConfigurableOption, configurableOptions, and per-rule declarations are all in place
- Minimal effort — likely just a Vite/Rollup config change to prevent property mangling, or ensuring the property is enumerable
Additional context
- Current UMD version tested: 5.9.7
- Consumer: Salesforce Inspector Reloaded browser extension
- The extension currently works around this with a hardcoded
flowScannerKnownConfigurableRules map
Description
Third-party consumers of the UMD build (SFIr) need to dynamically discover rule configuration capabilities. The source code already has the
ConfigurableOptioninterface and rules already declare theirconfigurableOptions, but this metadata doesn't survive into the published UMD bundle.Current behavior
getRules()returns rule instances withisConfigurable: true/falseconfigurableOptionsis not accessible on rule instances in the UMD buildexpressionvsthresholdand their defaultsExpected behavior
getRules()returns rule instances whereconfigurableOptionsis preserved and accessibleConfigurableOptionincludesname,type,description, anddefaultValueExample of what consumers could do
Why this matters
ConfigurableOption,configurableOptions, and per-rule declarations are all in placeAdditional context
flowScannerKnownConfigurableRulesmap