-
Notifications
You must be signed in to change notification settings - Fork 2
Use CDS extractor diagnostics instead of exit error codes #223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use CDS extractor diagnostics instead of exit error codes #223
Conversation
This commit addresses a regression in the behavior of the CDS extractor in some cases and/or for some CAP projects. Specifically, this commit: - Removes calls like `process.exit(1)` from the CDS extractor codebase. - Adds new diagnostic warnings for error conditions that had previously resulted in a non-zero exit code being returned from `cds-extractor.ts`. - Adds unit tests to ensure that fails if the `cds-extractor.ts` file contains any `process.exit(n)` call where `n != 0`. - Updates eslint configs for the CDS extractor to resolve reported errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This pull request improves error handling in the CDS extractor by replacing hard exits with diagnostic logging, ensuring the JavaScript extractor can continue processing even when CDS-specific operations fail. The changes focus on graceful degradation when CDS processing encounters issues while maintaining overall extraction functionality.
- Replace
process.exit(1)
calls with diagnostic logging and graceful continuation - Add new diagnostic functions for different failure scenarios (environment setup, dependency graph, dependency installation, no CDS projects)
- Update ESLint configuration to better separate JavaScript and TypeScript file handling
Reviewed Changes
Copilot reviewed 5 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
File | Description |
---|---|
extractors/cds/tools/cds-extractor.ts | Replace hard exits with diagnostic logging and graceful fallback to JavaScript extraction |
extractors/cds/tools/src/diagnostics.ts | Add new diagnostic functions for various CDS extractor failure scenarios |
extractors/cds/tools/test/cds-extractor.test.ts | Add comprehensive tests to verify exit code safety and diagnostic usage |
extractors/cds/tools/package.json | Update lint commands to include new test files and adjust coverage collection |
extractors/cds/tools/eslint.config.mjs | Refactor ESLint configuration with better separation between JS and TS files |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.
This commit addresses a regression in the behavior of the CDS extractor in some cases and/or for some CAP projects. Specifically, this commit: - Removes calls like `process.exit(1)` from the CDS extractor codebase. - Adds new diagnostic warnings for error conditions that had previously resulted in a non-zero exit code being returned from `cds-extractor.ts`. - Adds unit tests to ensure that fails if the `cds-extractor.ts` file contains any `process.exit(n)` call where `n != 0`. - Updates eslint configs for the CDS extractor to resolve reported errors.
…-js into cds-compile-retry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
What This PR Contributes
This pull request focuses on improving error handling and diagnostics in the CDS extractor, ensuring that failures in environment setup, dependency graph building, dependency installation, and project detection do not cause hard exits. Instead, diagnostics are logged and the extractor continues gracefully, allowing the JavaScript extractor to run even when CDS-specific steps fail. Additionally, the ESLint configuration is refactored for better separation between JavaScript and TypeScript files, and new tests verify these error handling improvements.