Conversation
This would cause the loader to fail if Jiti could not be found, or an earlier version of Jiti was used.
WalkthroughThe Changes
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
npm warn config production Use ✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/cli/src/loader/mixed.ts(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (1)
packages/cli/src/loader/mixed.ts (1)
packages/cli/src/loader/loader.ts (1)
UnsupportedFileLoaderError(37-42)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: test - windows-latest
- GitHub Check: test - ubuntu-latest
🔇 Additional comments (1)
packages/cli/src/loader/mixed.ts (1)
24-45: Approve the fixed fallback implementationThe changes correctly address the issue described in the PR objectives. By properly awaiting the asynchronous loader calls and ensuring the loop continues to try other loaders after removing a failing one, the fallback mechanism now works as intended even when certain loaders fail.
This would cause the loader to fail if Jiti could not be found, or an earlier version of Jiti was used.
|
Thanks! We have a failure we suspect was caused by the prior change and will be fixed by this PR. |
|
Sorry about that @geoffharcourt. I certainly do not take breaking stuff lightly but in this case it managed to pass through. We need a new test suite to properly test the loader. Note that release 5.4.1 includes this fix. |
|
Already in use, thanks! |
This would cause the loader to fail if Jiti could not be found, or an earlier version of Jiti was used.
The reason why I did not spot this earlier is that during manual testing, I used a symlink to the checkly package, which led to Node finding the appropriate version of
jitiin the checkly-cli repo (or in other words, from the node_modules folder relative to the actual file behind the symlink). So it seemed to work, but in fact did not. I have now correctly verified both the issue and the fix withnpm packand using the generated archive instead.Affected Components
Notes for the Reviewer
New Dependency Submission