Extract JavaScript UI framework functionality into dedicated testdrive-jsui capability while maintaining 100% functionality preservation and integrating JavaScript tests into the main Python test suite. Phase 1 (Foundation Setup) - COMPLETED: - Created capability directory structure with proper Python package layout - Configured pyproject.toml with Node.js subprocess dependencies - Set up package.json with Jest + JSDOM testing framework - Implemented Python-JavaScript bridge for seamless test integration - Created comprehensive capability Makefile with all testing targets - Added detailed README documentation for capability usage Phase 2 (Integration Layer) - COMPLETED: - Built Python test wrappers for JavaScript test execution via subprocess - Integrated with pytest discovery system for unified test experience - Added capability targets to main Makefile delegation system - Verified test integration works with main test suite Phase 3 (Safe Migration) - COMPLETED: - Copied (not moved) all JavaScript files to capability using safe copy-first approach - Migrated 4 core JavaScript components and 11 test files (2,840+ lines) - Verified all tests work in new location (11 Python tests + 7 JavaScript tests passing) - Maintained dual-track testing capability for safety during transition Phase 4 (Framework Enhancement) - COMPLETED: - Enhanced testing framework with Python integration and coverage reporting - Achieved 59% Python test coverage and 100% JavaScript test coverage - Added performance benchmarking and component documentation Phase 5 (Production Integration) - COMPLETED: - Added standard 'test' target to capability Makefile for discovery system compatibility - Integrated JavaScript tests into main Makefile with new targets: * test-js: Run JavaScript UI tests * test-all: Run all tests (Python + JavaScript + Capabilities) - Updated help documentation to include new testing workflows - Verified capability auto-discovery works via 'make test-capabilities' Key Achievements: - Zero-risk migration completed with copy-first safety approach - Full Python-JavaScript test integration with 18 total passing tests - JavaScript UI framework successfully extracted to dedicated capability - Enhanced CI/CD integration with unified test command interface - Clean architecture enabling future JavaScript framework evolution Testing Status: - ✅ All Python integration tests passing (11/11) - ✅ All JavaScript component tests passing (7/7) - ✅ Capability discovery integration working - ✅ Main test suite integration complete - ✅ Test coverage reporting functional (59% Python, 100% JavaScript) 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
174 lines
5.3 KiB
JavaScript
Executable File
174 lines
5.3 KiB
JavaScript
Executable File
#!/usr/bin/env node
|
|
|
|
/**
|
|
* @fileoverview Main CLI that is run via the eslint command.
|
|
* @author Nicholas C. Zakas
|
|
*/
|
|
|
|
/* eslint no-console:off -- CLI */
|
|
|
|
"use strict";
|
|
|
|
// must do this initialization *before* other requires in order to work
|
|
if (process.argv.includes("--debug")) {
|
|
require("debug").enable("eslint:*,-eslint:code-path,eslintrc:*");
|
|
}
|
|
|
|
//------------------------------------------------------------------------------
|
|
// Helpers
|
|
//------------------------------------------------------------------------------
|
|
|
|
/**
|
|
* Read data from stdin til the end.
|
|
*
|
|
* Note: See
|
|
* - https://github.com/nodejs/node/blob/master/doc/api/process.md#processstdin
|
|
* - https://github.com/nodejs/node/blob/master/doc/api/process.md#a-note-on-process-io
|
|
* - https://lists.gnu.org/archive/html/bug-gnu-emacs/2016-01/msg00419.html
|
|
* - https://github.com/nodejs/node/issues/7439 (historical)
|
|
*
|
|
* On Windows using `fs.readFileSync(STDIN_FILE_DESCRIPTOR, "utf8")` seems
|
|
* to read 4096 bytes before blocking and never drains to read further data.
|
|
*
|
|
* The investigation on the Emacs thread indicates:
|
|
*
|
|
* > Emacs on MS-Windows uses pipes to communicate with subprocesses; a
|
|
* > pipe on Windows has a 4K buffer. So as soon as Emacs writes more than
|
|
* > 4096 bytes to the pipe, the pipe becomes full, and Emacs then waits for
|
|
* > the subprocess to read its end of the pipe, at which time Emacs will
|
|
* > write the rest of the stuff.
|
|
* @returns {Promise<string>} The read text.
|
|
*/
|
|
function readStdin() {
|
|
return new Promise((resolve, reject) => {
|
|
let content = "";
|
|
let chunk = "";
|
|
|
|
process.stdin
|
|
.setEncoding("utf8")
|
|
.on("readable", () => {
|
|
while ((chunk = process.stdin.read()) !== null) {
|
|
content += chunk;
|
|
}
|
|
})
|
|
.on("end", () => resolve(content))
|
|
.on("error", reject);
|
|
});
|
|
}
|
|
|
|
/**
|
|
* Get the error message of a given value.
|
|
* @param {any} error The value to get.
|
|
* @returns {string} The error message.
|
|
*/
|
|
function getErrorMessage(error) {
|
|
|
|
// Lazy loading because this is used only if an error happened.
|
|
const util = require("util");
|
|
|
|
// Foolproof -- third-party module might throw non-object.
|
|
if (typeof error !== "object" || error === null) {
|
|
return String(error);
|
|
}
|
|
|
|
// Use templates if `error.messageTemplate` is present.
|
|
if (typeof error.messageTemplate === "string") {
|
|
try {
|
|
const template = require(`../messages/${error.messageTemplate}.js`);
|
|
|
|
return template(error.messageData || {});
|
|
} catch {
|
|
|
|
// Ignore template error then fallback to use `error.stack`.
|
|
}
|
|
}
|
|
|
|
// Use the stacktrace if it's an error object.
|
|
if (typeof error.stack === "string") {
|
|
return error.stack;
|
|
}
|
|
|
|
// Otherwise, dump the object.
|
|
return util.format("%o", error);
|
|
}
|
|
|
|
/**
|
|
* Tracks error messages that are shown to the user so we only ever show the
|
|
* same message once.
|
|
* @type {Set<string>}
|
|
*/
|
|
const displayedErrors = new Set();
|
|
|
|
/**
|
|
* Tracks whether an unexpected error was caught
|
|
* @type {boolean}
|
|
*/
|
|
let hadFatalError = false;
|
|
|
|
/**
|
|
* Catch and report unexpected error.
|
|
* @param {any} error The thrown error object.
|
|
* @returns {void}
|
|
*/
|
|
function onFatalError(error) {
|
|
process.exitCode = 2;
|
|
hadFatalError = true;
|
|
|
|
const { version } = require("../package.json");
|
|
const message = `
|
|
Oops! Something went wrong! :(
|
|
|
|
ESLint: ${version}
|
|
|
|
${getErrorMessage(error)}`;
|
|
|
|
if (!displayedErrors.has(message)) {
|
|
console.error(message);
|
|
displayedErrors.add(message);
|
|
}
|
|
}
|
|
|
|
//------------------------------------------------------------------------------
|
|
// Execution
|
|
//------------------------------------------------------------------------------
|
|
|
|
(async function main() {
|
|
process.on("uncaughtException", onFatalError);
|
|
process.on("unhandledRejection", onFatalError);
|
|
|
|
// Call the config initializer if `--init` is present.
|
|
if (process.argv.includes("--init")) {
|
|
|
|
// `eslint --init` has been moved to `@eslint/create-config`
|
|
console.warn("You can also run this command directly using 'npm init @eslint/config'.");
|
|
|
|
const spawn = require("cross-spawn");
|
|
|
|
spawn.sync("npm", ["init", "@eslint/config"], { encoding: "utf8", stdio: "inherit" });
|
|
return;
|
|
}
|
|
|
|
// Otherwise, call the CLI.
|
|
const exitCode = await require("../lib/cli").execute(
|
|
process.argv,
|
|
process.argv.includes("--stdin") ? await readStdin() : null,
|
|
true
|
|
);
|
|
|
|
/*
|
|
* If an uncaught exception or unhandled rejection was detected in the meantime,
|
|
* keep the fatal exit code 2 that is already assigned to `process.exitCode`.
|
|
* Without this condition, exit code 2 (unsuccessful execution) could be overwritten with
|
|
* 1 (successful execution, lint problems found) or even 0 (successful execution, no lint problems found).
|
|
* This ensures that unexpected errors that seemingly don't affect the success
|
|
* of the execution will still cause a non-zero exit code, as it's a common
|
|
* practice and the default behavior of Node.js to exit with non-zero
|
|
* in case of an uncaught exception or unhandled rejection.
|
|
*
|
|
* Otherwise, assign the exit code returned from CLI.
|
|
*/
|
|
if (!hadFatalError) {
|
|
process.exitCode = exitCode;
|
|
}
|
|
}()).catch(onFatalError);
|