-
-
Notifications
You must be signed in to change notification settings - Fork 14
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
App Router Examples #938
Labels
Comments
Hey there, thanks for the interest. Version 4 doesn't technically exist yet except in that section of the appendix (good eye!). I paused working on NTARH to work on something else, but NTARH is up next on my list 👍🏾 I hope to finish it before the end of this month and close out all open issues |
Xunnamius
added a commit
that referenced
this issue
Jan 15, 2024
## [4.0.0](v3.2.0...v4.0.0) (2024-01-15) ### 💥 BREAKING CHANGES 💥 * **Request URLs (e.g. `req.url`) will always be** `"ntarh://testApiHandler"`. This is instead of the old localhost string with the random port number, which is an implementation detail that should not have been exposed to end developers. * `NtarhParameters` has been superseded by `NtarhInit`, `NtarhInitAppRouter`, and `NtarhInitPagesRouter`. * **The `handler` option of `testApiHandler` (i.e.** `testApiHandler({ handler })`) has been renamed to `pagesHandler`. It is otherwise functionally equivalent. Those migrating from NTARH@<4, the process should be as simple as renaming `handler` to `pagesHandler` in your tests and getting on with your life. * `requestPatcher`, `reponsePatcher`, and `paramsPatcher` options of `testApiHandler({ ... })` can now be asynchronous and return Promises. `paramsPatcher` can additionally return a brand new `params` object that will overwrite the old one rather than merely augmenting it. * `testApiHandler({ ... })` now accepts the `appHandler` option. When this option is provided, the function signatures of the following options shift to support standard `Request`/`Response` parameters and return types where appropriate: `requestPatcher`, `responsePatcher`, and `paramsPatcher`. See the docs, or intellisense, for more details. * `requestPatcher`, `reponsePatcher`, and `paramsPatcher` options of `testApiHandler({ ... })` no longer support parenthetical shorthand notation. For example, the following will cause a type error: `testApiHandler({ paramsPatcher: (params) => (params.id = "some-id") })`. * This version of NTARH is now actively tracking a second Next.js internal export, one that is not guaranteed to be available before `next@14.0.4`. Therefore, versions of Next.js older than 14.0.4 **explicitly unsupported** when using the `appHandler` option. On the other hand, `pagesHandler` will always work regardless of Next.js version until Vercel eventually removes the Pages Router functionality entirely. * The `pagesHandler` option of `testApiHandler` (i.e. `testApiHandler({ pagesHandler })`) will **not** accept edge runtime routes. To test your edge runtime routes, use the `appHandler` option instead. * Minimum supported Node.js version is now 18.18.2 * Node-fetch has been replaced by Node's native fetch function. There may be subtle API changes between the two. #### ✨ Features * Land initial App Router support ([e2d8865](e2d8865)) <sup>closes [#938](#938), [#773](https://github.com/Xunnamius/next-test-api-route-handler/issues/773)</sup> * Retire use of node-fetch ([5574831](5574831)) <sup>closes [#946](https://github.com/Xunnamius/next-test-api-route-handler/issues/946)</sup> * **src:** warn when invoking testApiHandler with invalid property combos ([db599ac](db599ac)) #### 🪄 Fixes * Loosen type checking for `NextApiHandler`s ([fdfec8c](fdfec8c)) * **src:** deeply summon res.json() return value into our realm ([59f54a5](59f54a5)) * **src:** ensure all results of calling ::json on Requests and Responses are summoned into our realm ([5c5f9a4](5c5f9a4)) * **src:** ensure AsyncLocalStorage is available globally (might fix [#875](#875)) ([43680d9](43680d9)) * **src:** ensure global fetch is restored after testApiHandler terminates ([75d4e1f](75d4e1f)) * **src:** forcefully coerce request.body into a ReadableStream ([f715331](f715331)) * **src:** hoist globalThis.AsyncLocalStorage initialization to be as soon as possible ([85bb8fa](85bb8fa)) * **src:** normalize pagesHandler into NextApiHandler (esm<->cjs interop) ([0133e11](0133e11)) * Use more accurate return type for app router patchers ([62f1d0b](62f1d0b)) #### ⚙️ Build system * **husky:** ensure hooks do not run on rebase ([913cbd0](913cbd0)) * **package:** bump minimum supported node versions to maintained ([702cb44](702cb44)) * **package:** remove outdated properties ([dc23723](dc23723)) #### 🧙🏿 Refactored * **src:** ensure request url is consistent across router types ([d72ae87](d72ae87))
🎉 This issue has been resolved in version 4.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
According to the docs
NTARH got app router and edge route support in version 4.
.However, I have been unable to find any examples of tests using the app router. Additionally, it seems like the types require a
NextApiRequest
/NextApiReponse
,Finally, if I simply ignore the types, I see
API route returned a Response object in the Node.js runtime, this is not supported. Please use runtime: "edge" as an error in the response.
I am guessing this is all supported based on the docs, but don't see how. Any ideas?
The text was updated successfully, but these errors were encountered: