-
-
Notifications
You must be signed in to change notification settings - Fork 831
Remove short circuit preventing 'Failed to find any GraphQL type definitions' error from appearing #7407
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
base: master
Are you sure you want to change the base?
Conversation
…7082) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…7087) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…#7101) Bumps the actions-deps group with 1 update: [webpack](https://github.com/webpack/webpack). Updates `webpack` from 5.99.1 to 5.99.2 - [Release notes](https://github.com/webpack/webpack/releases) - [Commits](webpack/webpack@v5.99.1...v5.99.2) --- updated-dependencies: - dependency-name: webpack dependency-version: 5.99.2 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: actions-deps ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…7109) Bumps the actions-deps group with 1 update: [svelte](https://github.com/sveltejs/svelte/tree/HEAD/packages/svelte). Updates `svelte` from 5.25.8 to 5.25.9 - [Release notes](https://github.com/sveltejs/svelte/releases) - [Changelog](https://github.com/sveltejs/svelte/blob/main/packages/svelte/CHANGELOG.md) - [Commits](https://github.com/sveltejs/svelte/commits/svelte@5.25.9/packages/svelte) --- updated-dependencies: - dependency-name: svelte dependency-version: 5.25.9 dependency-type: direct:development update-type: version-update:semver-patch dependency-group: actions-deps ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…d whilst loading documents (ardatan#7093) * Throw custom NoDocumentFoundError when cannot find document when loading for libraries to handle * Add changeset * Improve error handling - Rename custom error to NoTypeDefinitionsFound to match the rest of implementation - Let custom error take pointerList and encapsulate error message logic - Update tests to handle sync vs async use cases - Concat rows instead of using template literal strings to have better formatting * Update changeset * Put back error message with indentation
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
* chore(deps): update dependency @urql/core to v6 * chore(dependencies): updated changesets for modified dependencies --------- Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
…nitions' error from appearing If you have a pointer that doesn't match any files containing graphql, `loadFile` should result in an error reporting that no graphql type definitions were identified. However, right now, if there is exactly one error produced by the loader, the meaningful error, the fact that no type definitions were identified, will be hidden. This can be very confusing if there error produced by the loader happens to be unrelated. An easy reproduction, using `graphql-codegen`: ``` /src Test.vue <script setup lang="ts"> import {Props} from 'props.ts'; defineProps<Props>(); </script> gqlType.ts import { graphql } from '@generated/graphql'; const MY_FRAGMENT = graphql(` fragment MyFragment on SomeType { id } `); /codegen /index.ts import type { CodegenConfig } from '@graphql-codegen/cli'; const config: CodegenConfig = { schema: './codegen/schema.config.ts', documents: ['src/**/*.vue', 'src/**/*.ts'], generates: { './generated/graphql/': { preset: 'client', config: { useTypeImports: true, }, }, }, }; export default config; package.json { "name": "test", "version": "1.0.0", "scripts": { "build:graphql-codegen": "graphql-codegen -c codegen/index.ts", }, "dependencies": { "vue": "3.5.18", "graphql": "16.6.0", }, "devDependencies": { "@graphql-codegen/cli": "3.3.0", "@graphql-codegen/client-preset": "3.0.1", } } ``` If you run `npm run build:graphql-codegen`, the reason codegen fails is because there are no graphql type definitions for any file matched by the .vue file matcher. However, the only error it will report is this: ``` [@vue/compiler-sfc] No fs option provided to `compileScript` in non-Node environment. File system access is required for resolving imported types. ``` This error is preventing the file Test.vue from being parsed, but it's not why graphql codegen in general is failing. If you were to add another vue file with a graphql type definition in it, that file would parse correctly and graphql-codegen would succeed. If you want graphql-codegen to work on the current project setup, you can remove the .vue file matcher from `codegen/index.ts`. This change results in the following output instead: ``` ✖ Failed to find any GraphQL type definitions in: src/**/*.vue; - [@vue/compiler-sfc] No fs option provided to `compileScript` in non-Node environment. File system access is required for resolving imported types. ``` I think this is much clearer.
|
📝 WalkthroughSummary by CodeRabbit
WalkthroughloadFile and loadFileSync now always throw an AggregateError when no results are produced but errors were collected; previously a single error could be rethrown. No API signature changes. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Caller
participant loadFile
participant Readers
Caller->>loadFile: loadFile(...)
rect rgba(230,240,255,0.6)
loadFile->>Readers: read/resolve sources
Readers-->>loadFile: results[] and errors[]
end
alt results.length > 0
loadFile-->>Caller: return results[]
else results.length == 0 and errors.length > 0
note over loadFile: behavior changed — aggregate errors
loadFile-->>Caller: throw AggregateError(errors)
else no results and no errors
loadFile-->>Caller: return []
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related issues
Suggested reviewers
Poem
Tip 🔌 Remote MCP (Model Context Protocol) integration is now available!Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats. 📜 Recent review detailsConfiguration used: CodeRabbit UI 💡 Knowledge Base configuration:
You can enable these sources in your CodeRabbit configuration. 📒 Files selected for processing (2)
💤 Files with no reviewable changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
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.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/load/tests/loaders/schema/integration.spec.ts (1)
22-29
: Prefer rejects-based assertion over try/catch for async error tests.Using Jest’s
rejects
is more concise and avoids the manual sentinelexpect(true).toBeFalsy()
.Proposed refactor:
- try { - await load(schemaPath, { - loaders: [new CodeFileLoader()], - cwd: __dirname, - }); - expect(true).toBeFalsy(); // should throw - } catch (e: any) { - expect(e).toBeInstanceOf(AggregateError); - expect(Array.isArray(e.errors)).toBe(true); - expect(e.errors.length).toBeGreaterThan(0); - expect(e.errors.some((err: unknown) => String(err).includes('SyntaxError'))).toBe(true); - // Optional: expect(String(e.message)).toContain('Failed to find any GraphQL type definitions'); - } + await expect(load(schemaPath, { + loaders: [new CodeFileLoader()], + cwd: __dirname, + })).rejects.toMatchObject({ + name: 'AggregateError', + errors: expect.arrayContaining([ + expect.anything(), // at least one nested error + ]), + });If you want to keep the message check, you can add a second expectation with
.rejects
using a custom matcher, or fall back to try/catch just for that assertion.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
yarn.lock
is excluded by!**/yarn.lock
,!**/*.lock
📒 Files selected for processing (1)
packages/load/tests/loaders/schema/integration.spec.ts
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: Unit Test on Node 18 (ubuntu-latest) and GraphQL v15
- GitHub Check: Unit Test on Node 18 (windows-latest) and GraphQL v16
- GitHub Check: Unit Test on Node 22 (ubuntu-latest) and GraphQL v16
- GitHub Check: Unit Test on Node 18 (ubuntu-latest) and GraphQL v16
- GitHub Check: Type Check on GraphQL v15
- GitHub Check: Full Check on GraphQL v16
- GitHub Check: Unit Test on Bun
expect(e).toBeInstanceOf(AggregateError); | ||
expect(e.errors.length).toEqual(0); | ||
expect(e.errors[0].toString()).toContain(`SyntaxError`); |
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.
Fix contradictory assertions on AggregateError.errors (test currently cannot pass).
You assert errors.length === 0
and then immediately access errors[0]
. If length
is zero, errors[0]
is undefined and .toString()
will throw, making the test fail regardless of implementation. Since the new behavior aggregates loader errors, errors.length
should be ≥ 1. Also make the SyntaxError check robust in case there are multiple nested errors.
Apply this diff:
- expect(e).toBeInstanceOf(AggregateError);
- expect(e.errors.length).toEqual(0);
- expect(e.errors[0].toString()).toContain(`SyntaxError`);
+ expect(e).toBeInstanceOf(AggregateError);
+ expect(Array.isArray(e.errors)).toBe(true);
+ expect(e.errors.length).toBeGreaterThan(0);
+ // At least one nested error should be a SyntaxError (from the code loader parsing failure)
+ expect(e.errors.some((err: unknown) => String(err).includes('SyntaxError'))).toBe(true);
+ // Optional: lock in the top-level summary message emitted when no type defs are found
+ // expect(String(e.message)).toContain('Failed to find any GraphQL type definitions');
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
expect(e).toBeInstanceOf(AggregateError); | |
expect(e.errors.length).toEqual(0); | |
expect(e.errors[0].toString()).toContain(`SyntaxError`); | |
expect(e).toBeInstanceOf(AggregateError); | |
expect(Array.isArray(e.errors)).toBe(true); | |
expect(e.errors.length).toBeGreaterThan(0); | |
// At least one nested error should be a SyntaxError (from the code loader parsing failure) | |
expect(e.errors.some((err: unknown) => String(err).includes('SyntaxError'))).toBe(true); | |
// Optional: lock in the top-level summary message emitted when no type defs are found | |
// expect(String(e.message)).toContain('Failed to find any GraphQL type definitions'); |
🤖 Prompt for AI Agents
In packages/load/tests/loaders/schema/integration.spec.ts around lines 29 to 31,
the test has contradictory assertions (it expects e.errors.length === 0 then
accesses e.errors[0]) which will always fail; change the assertions to require e
to be an AggregateError and that e.errors.length is >= 1, then verify at least
one nested error string contains "SyntaxError" (e.g., use a .some(...) or
equivalent over e.errors to check toString/includes), making the SyntaxError
check resilient to multiple nested errors.
Not sure I understand the motivation behind this change. If it is an issue on codegen, then it needs to be fixed there not here. |
Description
If you have a pointer that doesn't match any files containing graphql,
loadFile
should result in an error reporting that no graphql type definitions were identified. However, right now, if there is exactly one error produced by the loader, the meaningful error, the fact that no type definitions were identified, will be hidden. This can be very confusing if there error produced by the loader happens to be unrelated.An easy reproduction, using
graphql-codegen
:If you run
npm run build:graphql-codegen
, the reason codegen fails is because there are no graphql type definitions for any file matched by the .vue file matcher. However, the only error it will report is this:This error is preventing the file Test.vue from being parsed, but it's not why graphql codegen in general is failing. If you were to add another vue file with a graphql type definition in it, that file would parse correctly and graphql-codegen would succeed. If you want graphql-codegen to work on the current project setup, you can remove the .vue file matcher from
codegen/index.ts
.This change results in the following output instead:
I think this is much clearer.
Related # (issue)
#7406
Type of change
Please delete options that are not relevant.
expected)
How Has This Been Tested?
Before, running graphql-codegen on a project with a matcher that results in no graphql type definitions and one parsing error:
After, running graphql-codegenon a project with a matcher that results in no graphql type definitions and one parsing error:
Test Environment:
@graphql-tools/load
: 8.0.0Checklist:
CONTRIBUTING doc and the
style guidelines of this project