docs: update Firecrawl example
The current example doesn't work anymore. FirecrawlApp is now FirecrawlAppV1, and ScrapeResponse isn't exposed. So I updated the example to use the updated SDK, trying to keep this new example as close to the original as I could.
✅ Checklist
- [x] I have followed every step in the contributing guide
- [x] The PR title follows the convention.
- [x] I ran and tested the code works
Testing
I tested the updated workflows on cloud.trigger.dev.
Changelog
Update the Firecrawl example to use the updated Firecrawl SDK.
Screenshots
💯
⚠️ No Changeset found
Latest commit: 5f439573897a9a83a0040be25d5e21655a33581f
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
Walkthrough
The pull request updates documentation in a guide file to reflect API changes. It modifies example code by renaming the default import from FirecrawlApp to Firecrawl, updating method calls from crawlUrl() to crawl() and scrapeUrl() to scrape(), adjusting error handling for the crawl operation to check for failed status, and simplifying the scrape operation by removing explicit type annotations and success validation.
Estimated code review effort
🎯 2 (Simple) | ⏱️ ~10 minutes
- Single documentation file with consistent pattern changes (method and import renames)
- Changes are homogeneous and repetitive in nature (same refactoring applied across examples)
- Low logic density; primarily cosmetic and structural updates to code examples
- No public API signature changes to validate against
Pre-merge checks and finishing touches
✅ Passed checks (2 passed)
| Check name | Status | Explanation |
|---|---|---|
| Title check | ✅ Passed | The title concisely describes the main change: updating the Firecrawl example to work with the current SDK. |
| Description check | ✅ Passed | The PR description follows the template with all required sections completed, including testing details and screenshots. |
✨ Finishing touches
🧪 Generate unit tests (beta)
- [ ] Create PR with unit tests
- [ ] Post copyable unit tests in a comment
📜 Recent review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📥 Commits
Reviewing files that changed from the base of the PR and between 9fdf91a1c4587358b924acec3c5c68e950d154e3 and 5f439573897a9a83a0040be25d5e21655a33581f.
📒 Files selected for processing (1)
-
docs/guides/examples/firecrawl-url-crawl.mdx(4 hunks)
🔇 Additional comments (1)
docs/guides/examples/firecrawl-url-crawl.mdx (1)
23-52: Example 1 updates look good; verify Example 2 error handling consistency.The crawl example correctly updates to use the new Firecrawl SDK API (import, constructor, and method names), and the added error handling at lines 44–46 is appropriate for a network operation.
However, Example 2 (scrape) at lines 68–91 has no error handling, while the crawl example does. Since both are network operations that can fail, consider whether the scrape operation should also check for failure status.
Can you confirm whether the scrape operation can fail in the updated SDK and should include error handling similar to the crawl example? If so, apply a similar error check:
const scrapeResult = await firecrawlClient.scrape(url, { formats: ["markdown", "html"], }); + + if (scrapeResult.status === "failed") { + throw new Error(`Failed to scrape: ${url}`); + }Alternatively, if error handling is not needed for scrape, please clarify why the operations differ.
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands and usage tips.