[Snyk] Upgrade babel-plugin-relay from 5.0.0 to 18.2.0 #10
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Snyk has created this PR to upgrade babel-plugin-relay from 5.0.0 to 18.2.0. See this package in npm: babel-plugin-relay See this project in Snyk: https://app.snyk.io/org/erkansukgen/project/b4f646d1-de8c-49bd-8019-c589052dc75c?utm_source=github&utm_medium=referral&page=upgrade-pr
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Snyk has created this PR to upgrade babel-plugin-relay from 5.0.0 to 18.2.0.
ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.
The recommended version is 37 versions ahead of your current version.
The recommended version was released a month ago.
Release notes
Package name: babel-plugin-relay
Relay version 18.2.0 comes with several bug fixes and improvements!
New compiler capability: Relay Codemods
Codemods are tools which enable you to programmatically update your code. These are especially helpful if you want to upgrade an API across your whole codebase without needing to manually change each call site. The Relay compiler, with its understanding of your GraphQL snippets, is well positioned to help with these kinds of tasks. In Relay 18.2.0 we are introducing Relay Codemods.
We currently support two different codemods:
mark-dangerous-conditional-fragment-spreadsmarks places where@ aliasis required to make a fragment spread safe. This can enable you to turn on theenforce_fragment_alias_where_ambiguousfeature flag. Learn more in the@ aliasdocs.remove-unnecessary-required-directivesidentifies places where@ requiredis unnecessary because it's used on a non-nullable field within a fragment or query that is@ throwOnFieldError, and removes the@ requireddirective.We are looking forward to helping Relay users with more codemods in the future!
New experimental hook for pagination with prefetching
It is often possible to speed up list pagination by pre-loading one or more pages of results ahead of what the user is currently viewing. Our previous APIs made this difficult to fetch the next page of data without also rendering it at the same time. We are currently exploring an experimental API to make it easy to manage paginated lists with prefetching.
Read more in the docs: usePrefetchableForwardPaginationFragment
Expand places where @ catch can be used
The
@ catchdirective can now be used on fragments, queries, mutations and aliased inline fragments. This enables more flexibility in controlling how field errors are handled.Bug fixes
Improvements
@ aliasenforcement by Jordan EldredgeDocumentation Improvements
Miscellaneous
Experimental Changes
Following up from our v18.0.0 release last month, v18.1.0 provides a number of fixes and improvements, adds some new experimental APIs, and ships some long-running experimental features as stable.
Relay Resolvers are now stable
For the past several years we've been iterating on Relay Resolvers which provided a structured and typesafe way to model client state and derived data in your GraphQL graph. As of this release, Relay Resolvers are enabled by default and no-longer experimental. As part of this stabilization we shipped fixes for Relay Resolvers when used with TypeScript and fixed a few edge cases related to how errors encountered by resolvers are handled.
Improvements to error @ catch
We released
@ catchin v18.0.0 and are very excited about the capabilities it enables. Check out Itamar Kestenbaum's GraphQL conf talk about it here: Build Confidently: How @ Catch and Error Handling Pave Way in Field Nullability.Since that release we've made a few improvements:
@ catchdirective that are marked as@ semanticNonNullin the schema now generate non-nullable TypeScript/Flow types. See semantic nullability.@ catchno-longer include the error message. This is because GraphQL error messages are generally not safe to show to users. These error messages can still be accessed by the field logger provided to your Relay Environment. In the future we plan to let users opt into allowing safe error messages through to product code.Compiler Error Reporting
We've improved how errors are reported by the Relay compiler to ensure we report as many errors as possible, and each error includes sufficient context.
New "Copy Operation" VSCode command
Our VSCode extension now includes a command to quickly copy the full text of a query directly from within your editor.
Experimental APIs for reading fragment data outside of React
In some cases it can be useful to read a fragment outside of a React hook. However, doing this requires handling a number of concerns.
@ deferor Relay Resolver suspense).@ throwOnFieldError,@ required(action: THROW))To enable users to read fragment data while correctly handling these cases, we've added two experimental APIs:
observeFragment: Read a fragment as a stream of states where each state might be loading, error, or value.waitForFragmentData: Read a fragment as a promise which will resolve when data is available, or reject if an error is encountered.Docs
Thanks to members of our community for submitting pull requests to improve our docs:
Improvements
Experimental
We are always continuing to evolve and improve Relay. These changes are part of features or implementations which are either in progress or are being experimented with internally.
With version 18, the Relay team at Meta and our community of contributors have made several significant improvements to Relay:
@ aliasreleased as stable@ catchto detect and granularly handle field errors@ throwOnFieldErrorand@ semanticNonNullto avoid having to handle the nullability of fields which are only null in the case of error.Read all about them in more detail below:
Breaking Changes
Improved validation of field and fragment arguments
Previously we were not correctly type-checking arguments passed to client-defined fields, such as Relay Resolvers and Client Schema Extensions. This new release adds that validation. If you need to opt out of this validation for any reason, you can enable the
disable_full_argument_type_validationcompiler feature flag.Major features
@ alias fragment aliases released as stable
Aliased fragments are a Relay feature that lets you access fragments spreads and inline fragments as named properties. This can be especially helpful for fragments which might be conditionally fetched due to
@ skip/@ includeor type conditions which might not match. With@ aliasthese fragments get typed as nullable properties allowing you to check at runtime if they've matched or not before trying to use the data.Read more about @ alias
@ catch
@ catch, enabled by default will let you check at runtime if a field errored. This can allow you to disambiguate between true nulls returned by your server, and fields which are null due to field level errors.Read more about @ catch
@ throwOnFieldError
@ throwOnFieldErrorcan be added to fragments and queries and will cause any field errors within that fragment/query to throw when read. This ensures that all null values you encounter are true nulls as returned by your field resolvers on the server, and not field level errors that have been coerced to null.Read more about @ throwOnFieldError
Semantic Nullability
@ throwOnFieldErrorunlocks a powerful new feature when combined with a schema that has fields annotated with@ semanticNonNull.@ semanticNonNullcan be added to fields which have been made nullable in the schema only to enable more robust error handling, but are not expected to return null expect in the case of errors.Within fragments or queries annotated with
@ throwOnFieldError, fields annotated with@ semanticNonNullwill be typed as non-nullable. This has the potential to dramatically reduce the number of null checks you need to perform inside your product code, while also making your product code more "correct" by treating all field errors as explicit errors.Read more about Semantic Nullability
Relay Resolvers can now have access to context
Thanks for Mark Polak and Drew Atkinson from Microsoft, Relay Resolvers can now be configured to accept a shared context object, similar to standard GraphQL resolvers.
Pull Request
Read more about Resolver context
Ability to opt out of Relay Compiler source control integration
Thanks also to for Mark Polak from Microsoft, the Relay compiler config now supports the option
"noSourceControl": truewhich will ask the Relay compiler to not automatically try to add/remove files from Git or Mercurial.Pull Request
Editor Integration Improvements
Thanks to Tobias Tengler, Relay's editor support now includes:
Additional runtime logging integrations
Additional Improvements
Documentation Improvements
Miscellaneous
Experimental Changes
IdOfby Tianyu Yao