Distribute @apollo/server-integration-testsuite as CJS (correctly)
#7055
Conversation
✅ Deploy Preview for apollo-server-docs ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit e646523:
|
|
@tobiasdiez I've tested the build (produced by codesandbox: https://ci.codesandbox.io/status/apollographql/apollo-server/pr/7055/builds/306007) in the h3 repo on this PR: When running vitest via @SimenB it seems like our published testsuite is violating Jest expectations of usage (or vitest is exhibiting unexpected behavior in the h3 case in the PR above). Is there a correct way or pattern to go about exporting and publishing a testsuite that we might be missing? |
|
@tobiasdiez reports that he doesn't expect this to work in I am still curious to know about whether we're going about this package the right way at all. Things seem to be working, but that |
|
I have zero idea how vitest works or how it works/interops with Jest - I've never used it or even looked at it 😅 |
|
@SimenB it's being compiled and distributed as a package for use within jest. Example usage here: Sounds like we're just getting away with it. |
|
OK, so it's OK for there to be |
|
Yeah, as long as it's still a |
|
The PR looks good to my limited understanding of the issues. My one bit of confusion is — if we're only going to build this major part of our test suite as CJS, maybe we shouldn't be trying to run our tests as ESM? jest.config.base.js has |
|
…7055) Right now the integration testsuite package declares `"type": "module"` but builds as CJS. This seems to be problematic for some integrations, and we should resolve the misconfiguration. This also moves the tsconfig/build "things" over to the CJS branch of our build step. This also removes the ESM configuration options for how we run jest/ts-jest in this repo. Confirmed this doesn't cause a regression in our local dev in that a change in test code is immediately reflected in a test run without running an additional build. Fixes #7042 <!-- First, 🌠 thank you 🌠 for taking the time to consider a contribution to Apollo! Here are some important details to follow: * ⏰ Your time is important To save your precious time, if the contribution you are making will take more than an hour, please make sure it has been discussed in an issue first. This is especially true for feature requests! * 💡 Features Feature requests can be created and discussed within a GitHub Issue. Be sure to search for existing feature requests (and related issues!) prior to opening a new request. If an existing issue covers the need, please upvote that issue by using the 👍 emote, rather than opening a new issue. * 🔌 Integrations Apollo Server has many web-framework integrations including Express, Koa, Hapi and more. When adding a new feature, or fixing a bug, please take a peak and see if other integrations are also affected. In most cases, the fix can be applied to the other frameworks as well. Please note that, since new web-frameworks have a high maintenance cost, pull-requests for new web-frameworks should be discussed with a project maintainer first. * 🕷 Bug fixes These can be created and discussed in this repository. When fixing a bug, please _try_ to add a test which verifies the fix. If you cannot, you should still submit the PR but we may still ask you (and help you!) to create a test. * 📖 Contribution guidelines Follow https://github.com/apollographql/apollo-server/blob/main/CONTRIBUTING.md when submitting a pull request. Make sure existing tests still pass, and add tests for all new behavior. * ✏️ Explain your pull request Describe the big picture of your changes here to communicate to what your pull request is meant to accomplish. Provide 🔗 links 🔗 to associated issues! We hope you will find this to be a positive experience! Open source contribution can be intimidating and we hope to alleviate that pain as much as possible. Without following these guidelines, you may be missing context that can help you succeed with your contribution, which is why we encourage discussion first. Ultimately, there is no guarantee that we will be able to merge your pull-request, but by following these guidelines we can try to avoid disappointment. -->
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @apollo/server-integration-testsuite@4.0.2 ### Patch Changes - [#7035](#7035) [`b3f400063`](b3f4000) Thanks [@barryhagan](https://github.com/barryhagan)! - Errors resulting from an attempt to use introspection when it is not enabled now have an additional `validationErrorCode: 'INTROSPECTION_DISABLED'` extension; this value is part of a new enum `ApolloServerValidationErrorCode` exported from `@apollo/server/errors`. - [#7066](#7066) [`f11d55a83`](f11d55a) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Add a test to validate error message and code for invalid operation names via GET - [#7055](#7055) [`d0d8f4be7`](d0d8f4b) Thanks [@trevor-scheer](https://github.com/trevor-scheer)! - Fix build configuration issue and align on CJS correctly - Updated dependencies \[[`b3f400063`](b3f4000)]: - @apollo/server@4.0.2 ## @apollo/server@4.0.2 ### Patch Changes - [#7035](#7035) [`b3f400063`](b3f4000) Thanks [@barryhagan](https://github.com/barryhagan)! - Errors resulting from an attempt to use introspection when it is not enabled now have an additional `validationErrorCode: 'INTROSPECTION_DISABLED'` extension; this value is part of a new enum `ApolloServerValidationErrorCode` exported from `@apollo/server/errors`. Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Right now the integration testsuite package declares
"type": "module"but builds as CJS. This seems to be problematic for some integrations, but we should resolve the misconfiguration regardless.This also moves the tsconfig/build "things" over to the CJS branch of our build step.
Confirmed this doesn't cause a regression in our local dev in that a change in test code is immediately reflected in a test run without running an additional build.
Fixes #7042