feat: Add white-label build pipeline for plugin forks

[jnealey-godaddy]

Summary

• Adds a config-driven build pipeline that transforms all branded identifiers at build time, so forkers edit one file (white-label.json) and run npm run white-label:build to get a fully rebranded plugin in dist/
• Source files stay untouched — forkers can pull upstream updates cleanly
• Includes wp-env toggle for local testing of the white-labeled build

What gets rebranded

Plugin name, text domain, block namespace (designsetgo/accordion → myblocks/accordion), CSS prefix (dsgo- → mb-), short prefix (dsgFadeIn → mbFadeIn), PHP namespace, constants, function prefixes, REST routes, pattern categories, post type slug, meta keys, option names, file names, and plugin header metadata.

How it works

1. Webpack phase — string-replace-loader transforms JS/JSX at compile time; custom loader transforms block.json files
2. Post-build phase — Node script copies PHP, patterns, CSS, and remaining JS/JSON to dist/, applying transformations and renaming branded filenames
3. No white-label.json = no-op — default builds are completely unaffected

New npm scripts

Script	Purpose
white-label:build	Validate config + webpack build + post-build transform to dist/
white-label:zip	Build + package as installable .zip
white-label:validate	Validate config only
white-label:clean	Remove dist/
wp-env:white-label	Build + enable wp-env with dist/
wp-env:white-label:reset	Revert wp-env to source

Verified

• Zero remaining branded references in dist/ across PHP, JS, CSS, and JSON (excluding vendor/ and languages/)
• Default build (no white-label.json) produces identical output to current behavior
• File renaming works (e.g., class-dsgo-handlers.php → class-mb-handlers.php)

Test plan

• Delete white-label.json, run npm run build — confirm output matches current behavior
• Copy white-label.json.example to white-label.json, run npm run white-label:build
• Verify grep -r "designsetgo\|dsgo-\|_dsg_\|DesignSetGo\|DESIGNSETGO" dist/ returns zero results (excluding vendor/languages)
• Run npm run wp-env:white-label then npm run wp-env:start — plugin should activate without errors
• Verify blocks register and render in the editor
• Run npm run wp-env:white-label:reset to revert
• Run npm run white-label:zip — verify installable zip is produced

🤖 Generated with Claude Code

[claude]

Claude finished @jnealey88's task in 3m 8s —— View job

---

Code Review Complete

I've completed a comprehensive security and code quality review of the white-label build pipeline. The implementation is well-structured overall, but there are several security issues and code quality improvements needed.

---

Summary

Issues Found: 12 total

• Critical: 0
• High: 2 (Path traversal, Command injection risk)
• Medium: 3 (JSON parsing, Race condition, Error recovery)
• Low: 7 (Validation, error handling, code quality)

---

Critical Issues Requiring Immediate Attention

🔴 High Severity Issues

1. Path Traversal Vulnerability (scripts/white-label-php.js:279)

   • User-controlled config.logoPath is used directly in file operations without validation
   • Could allow copying sensitive files (.env, credentials) into the dist build
   • Fix: Validate that the resolved path stays within the project directory

2. Command Injection Risk (scripts/white-label-zip.js:58)

   • While execFileSync is safer than exec, defense-in-depth requires validating pluginSlug before use
   • Scripts can be run independently, bypassing the validation script
   • Fix: Add validation at point of use

🟡 Medium Severity Issues

3. JSON Parsing Vulnerability (scripts/white-label-replacements.js:65)

   • No error handling or type validation for JSON.parse()
   • Could crash on invalid JSON or cause errors with non-object values
   • Fix: Add try-catch and validate parsed value is an object

4. Race Condition (scripts/white-label-php.js:157)

   • Check-then-delete pattern creates potential race condition
   • Fix: Remove redundant existsSync check (force:true already handles it)

5. Error Recovery Issue (scripts/white-label-zip.js:55)

   • If zip command fails after renaming dist/, cleanup might fail
   • Could leave directory in wrong state
   • Fix: Use symlink instead of rename, or validate zip exists first

---

Additional Issues (Lower Priority)

Code Quality & Maintainability

6. Missing Error Handling (scripts/white-label-php.js:103)

   • File operations lack try-catch blocks
   • Build will crash with unhelpful errors if file operations fail

7. Inefficient Array Operations (webpack.config.js:73)

   • Multiple filter/map operations on same array
   • Empty rules might be added to webpack config

8. Missing Validation Logic (scripts/white-label-validate.js:197)

   • Comment mentions prefix collision check but code is missing
   • Could lead to replacement conflicts

9. Validation Inconsistency (scripts/white-label-validate.js:28, 107, 162)

   • JSON parsing lacks type checking
   • Meta key prefix pattern doesn't allow underscores throughout
   • CSS prefix "recommendation" is treated as hard error

Documentation

10. Misleading Comment (webpack.config.js:67)

    • Comment about regex escaping could be clearer

11. Filename Replacement Behavior (scripts/white-label-php.js:71)

    • Broad string replacement in filenames not documented
    • Could have unintended effects (likely acceptable but should be documented)

---

Positive Observations

✅ Good architectural decisions:

• Clear separation between webpack transformations and post-build transformations
• Config validation runs before build
• No-op when config matches defaults
• Comprehensive replacement coverage (PHP, JS, CSS, block.json)
• Good use of path.resolve() to prevent most path issues

✅ Security considerations already in place:

• Uses execFileSync instead of exec (prevents most command injection)
• Validation script has strong regex patterns
• Source files remain untouched (dist/ only)

✅ Code quality:

• Well-documented with clear comments
• Logical file organization
• Handles edge cases like missing vendor/ directory

---

Recommendations

Before Merging:

1. Fix the High severity issues (path traversal and command injection defense)
2. Add JSON parsing error handling (Medium severity)
3. Add error handling to file operations (prevents cryptic build failures)

Nice to Have:

4. Consider adding a comprehensive test suite for the transformation logic
5. Add integration test that validates zero branded references in dist/
6. Document the filename replacement behavior explicitly
7. Add validation that zip command exists before attempting to create archive

---

Overall Assessment

This is a well-designed white-label system with good separation of concerns and comprehensive coverage of branded identifiers. The main concerns are:

1. Security: Path traversal vulnerability needs immediate fix
2. Robustness: Add error handling to prevent cryptic failures
3. Defense in depth: Validate user input at point of use, not just at validation time

With the security fixes applied, this would be a solid, production-ready white-label build pipeline.

---

[claude]

SEVERITY: Medium - JSON Parsing Vulnerability

Problem: JSON.parse() is called without error handling, and there's no validation that the parsed content is actually an object. If a malicious actor provides invalid JSON or a non-object value (like "string", null, 123, []), this will cause unhandled errors or unexpected behavior.

Security Impact:

• Invalid JSON could crash the build process
• Non-object JSON values (arrays, strings, primitives) would cause Object.keys() on line 70 to throw
• No sanitization before using config values in file operations and string replacements

Fix:

let config;
try {
    config = JSON.parse(fs.readFileSync(configPath, 'utf8'));
    if (!config || typeof config !== 'object' || Array.isArray(config)) {
        throw new Error('Config must be an object');
    }
} catch (err) {
    console.error(`Error loading white-label.json: ${err.message}`);
    return null;
}

[jnealey-godaddy]

Fixed. Added try-catch with error message and type validation (must be a JSON object, not array/primitive). Returns null on failure so callers degrade gracefully.

[claude]

SEVERITY: High - Path Traversal Vulnerability

Problem: User-controlled config.logoPath is concatenated directly into a file path without any validation or sanitization. An attacker could provide a path like ../../../../etc/passwd or .env to copy sensitive files into the dist build.

Security Impact:

• Could expose sensitive files (.env, credentials, private keys)
• Could copy arbitrary files from the system into the distributed plugin
• The copied files would be included in the zip and potentially deployed to production

Fix:

if (config.logoPath && config.logoPath !== DEFAULTS.logoPath) {
    // Validate that logoPath doesn't escape the project directory
    const logoSrc = path.resolve(ROOT, config.logoPath);
    if (!logoSrc.startsWith(ROOT + path.sep) && logoSrc !== ROOT) {
        console.error(`Error: Logo path must be within project directory: ${config.logoPath}`);
        process.exit(1);
    }
    if (fs.existsSync(logoSrc)) {
        const logoDest = path.join(DIST, 'build', 'admin', 'assets');
        fs.mkdirSync(logoDest, { recursive: true });
        fs.copyFileSync(logoSrc, path.join(logoDest, path.basename(logoSrc)));
        console.log(`  Custom logo: ${config.logoPath}`);
    } else {
        console.warn(`  Warning: Logo file not found: ${config.logoPath}`);
    }
}

[jnealey-godaddy]

Fixed. Resolved path is validated against ROOT + path.sep before any file operation. Also renamed the copied logo to match the default filename (logo.png) so plugin code references stay valid.

[claude]

SEVERITY: High - Command Injection Vulnerability

Problem: User-controlled config.pluginSlug is passed directly to execFileSync as an argument without validation. While execFileSync is safer than exec, if the validation in white-label-validate.js is bypassed or the config is manually edited after validation, a malicious plugin slug could potentially cause issues.

Security Impact:

• Plugin slug could contain special characters that might be interpreted by the zip command
• While the regex in validation prevents most issues, defense in depth requires validation here too

Fix:

// Validate plugin slug before using in command
if (!/^[a-z][a-z0-9-]*$/.test(config.pluginSlug)) {
    console.error(`Error: Invalid plugin slug format: ${config.pluginSlug}`);
    process.exit(1);
}

try {
    execFileSync('zip', ['-r', zipName, config.pluginSlug], {
        cwd: ROOT,
        stdio: 'pipe',
    });

Note: This is defense in depth - the validation script should catch this, but scripts can be run independently.

[jnealey-godaddy]

Note: execFileSync doesn't use a shell, so this isn't actually command injection — arguments are passed as an array, not interpolated into a shell string. That said, added defense-in-depth: pluginSlug is validated at point-of-use with the same regex pattern, in case the script is run standalone.

[claude]

SEVERITY: Medium - Race Condition

Problem: There's a potential race condition between checking if DIST exists and removing it. If another process creates files in DIST between the existsSync check and rmSync, unexpected behavior could occur.

Fix: Use the force: true option (which you already have) but remove the existence check:

// Clean dist/ directory (force: true makes it safe even if it doesn't exist)
fs.rmSync(DIST, { recursive: true, force: true });
fs.mkdirSync(DIST, { recursive: true });

The force: true option already handles the case where the directory doesn't exist, so the check is redundant.

[jnealey-godaddy]

Fixed. Removed the existsSync check — rmSync with force:true handles non-existence. Also added a safety check that DIST is within ROOT before the rmSync call.

[claude]

SEVERITY: Low - Error Handling Inconsistency

Problem: The JSON parsing error handling here is better than in white-label-replacements.js, but it still doesn't validate that the parsed value is an object.

Fix:

let config;
try {
    config = JSON.parse(fs.readFileSync(configPath, 'utf8'));
    if (!config || typeof config !== 'object' || Array.isArray(config)) {
        throw new Error('Configuration must be a JSON object, not an array or primitive');
    }
} catch (err) {
    console.error(`Error: Invalid JSON in white-label.json:\n${err.message}`);
    process.exit(1);
}

[claude]

SEVERITY: Low - Validation Logic Flaw

Problem: The CSS prefix length validation (2-6 characters) only adds a warning to the errors array but doesn't actually enforce it as a requirement. However, very short prefixes (1 character) or very long ones could cause namespace collisions or readability issues.

Consider: Whether this should be a hard error instead of just adding to the errors array. Currently this is only a warning (based on "Recommended" in the message), but it gets added to the errors array which causes the script to exit with an error code.

Recommendation: Either make this a hard validation (change the message to "Must be 2-6 characters") or separate warnings from errors.

[jnealey-godaddy]

Fixed. Separated into a warnings array that prints before errors but doesn't block the build.

[claude]

SEVERITY: Low - Potential Filename Collision

Problem: The renameEntry function uses simple string replacement which could cause unintended replacements. For example, if a file is named my-designsetgo-test.php and the new textDomain is foo, it becomes my-foo-test.php. While this might be intentional, it could cause issues if there are legitimately named files that happen to contain the old prefix.

Consider:

• Whether filename replacement should only apply to files that start with the branded prefix
• Adding a comment explaining that any occurrence of the branded prefixes in filenames will be replaced

This is likely acceptable behavior for a white-label system, but worth documenting.

[claude]

SEVERITY: Low - Missing Error Handling

Problem: File operations (readFileSync, writeFileSync, copyFileSync) are performed without try-catch blocks. If any file operation fails (permissions, disk full, file locked), the entire build will crash with an unhandled exception.

Fix: Wrap the main execution in a try-catch:

try {
    const content = fs.readFileSync(srcPath, 'utf8');
    const transformed = transform(content, srcPath);
    fs.writeFileSync(destPath, transformed, 'utf8');
} catch (err) {
    console.error(`Error transforming ${srcPath}: ${err.message}`);
    throw err; // Re-throw to stop the build
}

Or at minimum, wrap the entire main execution block in a try-catch with a helpful error message.

[jnealey-godaddy]

Fixed. Wrapped the entire main execution block (steps 1-10) in a try-catch that prints the error and exits with code 1.

[claude]

SEVERITY: Medium - Error Recovery Issue

Problem: If execFileSync throws an exception after renaming dist/ to tempDir, the finally block will attempt to rename it back. However, if the error occurred because the zip command doesn't exist or another system-level issue, the finally block could fail too, leaving the directory in the wrong state.

Additional Issue: If the script is interrupted (SIGINT/SIGTERM) between the rename operations, the dist/ directory could be left with the wrong name.

Fix: Consider using a more robust approach:

const tempDir = path.resolve(ROOT, config.pluginSlug);

// Check if temp dir already exists (shouldn't happen), clean it.
if (fs.existsSync(tempDir)) {
    fs.rmSync(tempDir, { recursive: true, force: true });
}

// Create symlink instead of rename for safer cleanup
try {
    fs.symlinkSync(DIST, tempDir, 'junction');
    
    execFileSync('zip', ['-r', zipName, config.pluginSlug], {
        cwd: ROOT,
        stdio: 'pipe',
    });
    console.log(`\nCreated: ${zipName}`);
} catch (err) {
    console.error(`Error creating zip: ${err.message}`);
    process.exit(1);
} finally {
    // Always cleanup symlink
    if (fs.existsSync(tempDir)) {
        fs.unlinkSync(tempDir);
    }
}

Or validate that zip command exists before any file operations.

[jnealey-godaddy]

Fixed. Added recovery logic at script start: if temp dir exists without dist/, it's treated as a leftover from a previous crash and restored. Also added existsSync guard in the finally block.

[claude]

SEVERITY: Low - Documentation Issue

Problem: The comment says "literal strings work correctly with flags: 'g'" which is misleading. The reason for escaping is that string-replace-loader converts the string to a RegExp when you provide the flags option.

Recommendation: Clarify the comment:

// Escape regex-special characters for string-replace-loader.
// The 'flags: g' option causes string-replace-loader to convert the search string 
// into a RegExp, so we must escape special characters to match literally.
const escapeRegExp = (s) => s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');

[claude]

SEVERITY: Low - Code Quality

Problem: The webpack rule is always added even if there are no literal rules (after filtering). This means an empty multiple: [] array would be passed to string-replace-loader.

Recommendation: Only add the rule if there are matches:

const literalRules = whiteLabelRules
    .filter((rule) => !(rule.search instanceof RegExp))
    .map((rule) => ({
        search: escapeRegExp(rule.search),
        replace: rule.replace,
        flags: 'g',
    }));

if (literalRules.length > 0) {
    whiteLabelModuleRules.push({
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        loader: 'string-replace-loader',
        options: {
            multiple: literalRules,
        },
    });
}

[claude]

SEVERITY: Low - Incomplete Validation

Problem: The metaKeyPrefix validation allows an optional leading underscore with the pattern /^_?[a-z][a-z0-9]*$/, but this pattern doesn't allow underscores in the middle of the prefix. For example, _my_prefix would fail validation even though it's a valid meta key format.

Issue: The pattern requires lowercase letter after the optional underscore, then only lowercase letters and numbers - no additional underscores allowed.

Fix: If underscores should be allowed throughout (like in option prefixes), change to:

if (required('metaKeyPrefix', 'Meta key prefix')) {
    if (!/^_?[a-z][a-z0-9_]*$/.test(config.metaKeyPrefix)) {
        errors.push(
            `Meta key prefix ("${config.metaKeyPrefix}") is invalid. Must be lowercase with optional leading underscore and underscores allowed throughout.`
        );
    }
}

Note: This matches the pattern used for optionPrefix and phpFunctionPrefix.

[jnealey-godaddy]

Fixed. Pattern updated to /^_?[a-z][a-z0-9_]*$/ to allow underscores mid-prefix.

[Copilot]

Pull request overview

This PR introduces a comprehensive white-label build system that enables forkers to rebrand the DesignSetGo plugin by editing a single configuration file (white-label.json) and running a build command. The transformation happens at build time via webpack loaders and post-build Node.js scripts, leaving source files unchanged so forks can cleanly pull upstream updates.

Changes:

• Adds config-driven transformation system that replaces all branded identifiers (plugin name, text domain, block namespace, CSS prefixes, PHP namespace, constants, function names, REST routes, and metadata)
• Implements two-phase transformation: webpack string-replace-loader for JS/JSX during compilation, and post-build Node.js scripts for PHP, CSS, patterns, and other assets
• Provides npm scripts for validation, building, packaging as installable zip, and local wp-env testing of white-labeled builds

Reviewed changes

Copilot reviewed 10 out of 12 changed files in this pull request and generated 20 comments.

Show a summary per file

File	Description
white-label.schema.json	JSON Schema defining all configuration fields with validation patterns for each identifier type
white-label.json.example	Example configuration file showing how to rebrand to "MyBlocks"
webpack.config.js	Adds string-replace-loader rules for JS/JSX transformation and custom loader for block.json files; includes cache invalidation for white-label config changes
scripts/white-label-replacements.js	Core module defining default values and building replacement rules for different file types (JS, PHP, CSS, JSON); provides applyReplacements utility
scripts/white-label-validate.js	Validates white-label.json against patterns and cross-field requirements before build
scripts/white-label-php.js	Post-build script that copies and transforms PHP, CSS, patterns, and other assets from source to dist/ with filename renaming
scripts/white-label-json-loader.js	Custom webpack loader that transforms block.json files during webpack compilation
scripts/white-label-zip.js	Creates installable WordPress plugin zip from dist/ directory
scripts/wp-env-white-label.js	Toggles wp-env to use white-labeled dist/ build for local testing
package.json	Adds white-label npm scripts and string-replace-loader dependency
package-lock.json	Lockfile update for string-replace-loader dependency
.gitignore	Ignores dist/ directory and white-label.json configuration file

[Copilot]

The toCamelCase function has a JSDoc comment but the description could be more precise. The function doesn't convert all strings to camelCase - it specifically handles hyphen-delimited strings. For example, "my_blocks" would not be converted to "myBlocks", and "MyBlocks" would remain "MyBlocks".

Consider updating the JSDoc to be more specific: "Convert a hyphen-delimited slug to camelCase by capitalizing the first character after each hyphen and removing the hyphens."

[Copilot]

The white-label build system introduces several critical transformation functions (applyReplacements, loadConfig, buildJsScssReplacements, etc.) but lacks automated test coverage. Given that this codebase has comprehensive unit tests for other features (as seen in tests/unit/), the white-label functionality should also have tests.

Key functions that should be tested:

• loadConfig: handling missing files, invalid JSON, default-matching configs
• applyReplacements: literal and regex replacements, edge cases
• buildXxxReplacements: ensure all expected transformations are generated
• Filename renaming: ensure branded filenames are correctly transformed
• Integration: end-to-end test of a simple white-label build

This is especially important since incorrect transformations could break the built plugin in subtle ways that might not be caught until deployment.

[Copilot]

The zip creation uses execFileSync with stdio: 'pipe', which means output is buffered in memory. For large plugins, this could cause memory issues. Additionally, if the 'zip' command is not available on the system (e.g., on Windows without Unix tools), this will fail without a clear error message.

Consider: 1) Checking if 'zip' command exists before attempting to execute, 2) Providing fallback instructions for Windows users, or 3) Using a Node.js-based zip library for cross-platform compatibility.

[Copilot]

The white-label configuration values (like pluginName, textDomain, etc.) are directly interpolated into file content, including PHP code and JSON. While the validation script checks format patterns, it doesn't sanitize for code injection. A malicious config could potentially inject code.

For example, if someone sets pluginName: 'MyPlugin"; malicious_code(); //', this could be interpolated into PHP strings or JavaScript.

Consider: 1) Adding explicit checks that config values don't contain quotes, semicolons, or other code-injection characters, or 2) Document that white-label.json should only be created by trusted developers (since it's a build-time tool, not runtime user input), or 3) Add escaping functions for different contexts (PHP strings, JS strings, JSON values).

[jnealey-godaddy]

Added validation in white-label-validate.js: pluginName, pluginDescription, and pluginAuthor now reject quotes, backticks, backslashes, dollar signs, and angle brackets. All other fields are already constrained by regex patterns that prevent injection.

[Copilot]

In buildJsScssReplacements, both 'designsetgo-' (line 142) and 'designsetgo' (line 148) are added as literal replacements. The sorting ensures longer matches come first, but 'designsetgo-' (13 chars) and 'designsetgo' (11 chars) would both match 'designsetgo-block'. The hyphenated version should match first due to length, but this creates fragile ordering dependency.

If for some reason the sort doesn't work as expected, 'designsetgo' could match first and create '{textDomain}-' which would then not match the 'designsetgo-' pattern.

Consider making the non-hyphenated replacement use a word boundary regex like \bdesignsetgo\b to avoid matching when followed by a hyphen, or add a comment explaining why the current approach is safe (because sorting guarantees order).

Suggested change

	literal('designsetgo', config.textDomain);
	// Use a regex so we don't match when immediately followed by a hyphen.
	rules.push({
	search: new RegExp(`\\b${DEFAULTS.textDomain}(?!-)\\b`, 'g'),
	replace: config.textDomain,
	from: DEFAULTS.textDomain,
	});

[Copilot]

The copyDirWithTransform function recursively copies directories but doesn't handle symlinks. If the source directory tree contains symbolic links, they will be followed and copied as regular files/directories, which could lead to infinite loops if there's a circular symlink, or unexpected duplication of content.

Consider adding symlink detection (using lstatSync instead of or in addition to readdirSync with withFileTypes) and either: 1) skip symlinks with a warning, 2) copy them as symlinks, or 3) document that symlinks are not supported.

[Copilot]

The white-label-replacements.js file is approaching 500 lines and contains multiple distinct responsibilities: config loading, JS replacements, PHP replacements, CSS replacements, block.json replacements, plugin header replacements, and the apply function. This exceeds the project's stated 300-line file size limit guideline.

Consider refactoring this into smaller modules, such as:

• white-label-config.js (loadConfig, DEFAULTS)
• white-label-rules-js.js (buildJsScssReplacements)
• white-label-rules-php.js (buildPhpReplacements, buildPluginHeaderReplacements)
• white-label-rules-css.js (buildCssReplacements)
• white-label-rules-json.js (buildBlockJsonReplacements)
• white-label-apply.js (applyReplacements)

[jnealey-godaddy]

Not splitting this file. The replacement rules are logically cohesive — all rule builders share DEFAULTS, toCamelCase, and the same structure. Scattering them across 5 files would make it harder to see the complete replacement picture and maintain ordering consistency. The 300-line guideline is for block files with mixed concerns, not data-heavy modules.

[Copilot]

The readme.txt transformation applies phpRules after replacing the plugin name in the header. However, phpRules includes a replacement for 'DesignSetGo' to config.pluginName (line 300 of white-label-replacements.js). This means the replacement will happen twice: once explicitly on line 262, and again via phpRules on line 265.

While this shouldn't cause issues (the second replacement is a no-op), it's redundant. Consider either removing the explicit replacement on lines 261-264, or excluding 'DesignSetGo' from phpRules when applied to readme.txt.

Suggested change

	// Replace plugin name in readme header (first line is "=== PluginName ===").
	readmeContent = readmeContent.replace(
	`=== ${DEFAULTS.pluginName} ===`,
	`=== ${config.pluginName} ===`
	);
	// Apply PHP-style white-label replacements to readme content (including plugin name).

[Copilot]

The loadConfig function silently returns null when white-label.json exists but all values match defaults. This could be confusing for users who create a config file expecting it to be used. Consider logging a message or adding a comment in the function explaining this behavior, or checking this condition in the validation script and warning the user.

[Copilot]

The renameSync operation is used to temporarily rename dist/ to the plugin slug for zipping. If the script crashes or is interrupted between the rename and the finally block (e.g., user kills the process), the dist/ directory will remain renamed and could cause confusion. While the try-finally helps, it won't catch SIGKILL or system crashes.

Consider: 1) Adding a warning comment about this edge case, or 2) Checking for and recovering from this state at the start of the script (if temp dir exists, rename it back before proceeding).

[jnealey-godaddy]

Fixed. Added recovery logic at script start that detects and restores a leftover temp dir from a previous interrupted run.