Following up on https://github.com/ts-rest/ts-rest/pull/80, I've transitioned the nest library to use req.query and req.params rather than parsing them from the URL. This now allows the usage of arrays and nested objects in query params. I've made sure that this use-case is also covered in the clients by changing convertQueryParamsToUrlString to use qs.stringify which is the same library used internally by express.js.

Also tweaked the Nest implementation such that the all contracts' AppRoutes are added to their respective methods' metadata. This happens only once during runtime at startup, and therefore does need to be added to each request object. This allows us to maintain a single instance of ApiRouteInterceptor in the IoC container across all routes.

I've also changed how the status and response body are returned from ApiRouteInterceptor. Throwing an HttpException meant that no other interceptors could have been used since the thrown exception goes straight to Nest's base exception filter.

Added some tests in the example-nest app.

Hey @oliverbutler First thanks for this amazing tool! I ran an error while using @ts-rest/react-query : No QueryClient set, use QueryClientProvider to set one (nx, cra/nest)

This problem happens only with the compiled package, I have no error when I copy the client from your monorepo and then create my own lib.

Context

Hope to officially close #66 without workarounds. To be clear, I do not want to merge these changes just yet, but I want to get at least the conversation going, and a PR started so that we can implement @ecyrbe 's suggestions or our own fix.

Background

On my NextJS webpack build, and several others, we observe the following error:

Server Error
Error: No QueryClient set, use QueryClientProvider to set one

This error happened while generating the page. Any console logs will be displayed in the terminal window.

Implementing this workaround no longer works for me (for some reason):

    if (options.isServer) {
      config.externals = ["@tanstack/react-query", ...config.externals];
    }
    const reactQuery = path.resolve(require.resolve("@tanstack/react-query"));
    console.log(reactQuery, 'converted ts-rest imports for react-query')
    config.resolve.alias["@tanstack/react-query"] = reactQuery;
    return config;
  },

According to #66 and @ecyrbe, the likely culprit is that exports are not being correctly interpreted by webpack. See: https://github.com/ecyrbe/zodios/issues/191#issuecomment-1288101919.

I released a temporary test version of @ts-rest/react-query here: https://www.npmjs.com/package/michaelangrivera-ts-rest-react-query, and I still see the same issue while implementing that suggestion.

Interestingly, though, the following works:

`const client = require('michaelangrivera-ts-rest-react-query')`

I guess this is to be expected, though, since ESM is failing and not common modules.

This is what the build looks like after nx build for that library:

{
  "name": "michaelangrivera-ts-rest-react-query",
  "version": "3.6.6",
  "description": "react-query client integration for @ts-rest",
  "license": "MIT",
  "main": "./index.cjs",
  "module": "./index.js",
  "typings": "index.d.ts",
  "exports": {
    ".": {
      "types": "./index.d.ts",
      "import": "./index.js",
      "require": "./index.cjs"
    },
    "./package.json": "./package.json"
  },
....
  "peerDependencies": {
    "react": "16.x.x || 17.x.x || 18.x.x",
    "zod": "3.x.x",
    "@tanstack/react-query": "4.x.x",
    "@ts-rest/core": "3.6.0"
  },
  "type": "module",
  "types": "./index.d.ts",
  "dependencies": {}
}

I tried the following changes (I published them, re-installed, and cleared .next cache):

• "generateExportsField": true, no luck
• only using esm under the format configuration, no luck

I'm wondering if changing type: to module in package.json would work any magic.

Let me know if you have any suggestions, and I can implement, test them, and then update this PR @oliverbutler @ecyrbe.

I could also be totally off, and this is actual a client instance issue with React Query and the way it's be initialized.

This whole effort may be futile as Next is moving away from webpack, but nonetheless, it may still be good to support webpack for legacy apps and people using webpack without Next.

First of all, congrats on building such a cool library! 🙌

It seems I've stumbled upon an unwanted behaviour, when calling a client router method that simply does a GET request without any required parameters:

I might be missing something, but it seems that the root cause is in the DataReturn type that's being applied where the args parameter is never optional:

// ts-rest/libs/ts-rest/core/src/lib/client.ts

/**
 * Returned from a mutation or query call
 */
export type DataReturn<TRoute extends AppRoute> = (
  args: Without<DataReturnArgs<TRoute>, never>
) => Promise<ApiRouteResponse<TRoute['responses']>>;

1 - Could we make args optional for "query calls" where there aren't any required path parameters?

Also, if the query property is specified on the contract:

const c = initContract();

export const contract = c.router({
  getMembers: {
    method: 'GET',
    path: 'members',
    responses: {
      200: c.response<{ members: Member[]; total: number }>(),
    },
    query: z.object({
      take: z.string().transform(Number).optional(),
      skip: z.string().transform(Number).optional(),
      search: z.string().optional(),
    }),
    summary: 'Get all members',
  },
});

It seems to become required on the client:

2 - Could we make query params optional?

Hi @oliverbutler

Thanks for this very interresting project.

Have you an example to integrate @ts-rest/open-api with @ts-rest/express ?

EDIT:

Below my local implementation

import { contract } from "./contract";
import { generateOpenApi } from "@ts-rest/open-api";
import { serve, setup } from "swagger-ui-express";

const openapi = generateOpenApi(contract, {
  info: { title: "Play API", version: "0.1" },
});

const apiDocs = Router();

apiDocs.use(serve);
apiDocs.get("/", setup(openapi));

app.use("/api-docs", apiDocs);

createExpressEndpoints(contract, router, app);

If the same zod object is used multiple times in the same contract object (query, body or response), it will use a $ref to refer to it's first occurrence. For the example in test code, it would have generated to following JSON schema.

"comments": {
  "anyOf": [
	{
	  "items": {
		"additionalProperties": false,
		"properties": {
		  "id": {
			"type": "number"
		  },
		  "title": {
			"type": "string"
		  }
		},
		"required": [
		  "id",
		  "title"
		],
		"type": "object"
	  },
	  "type": "array"
	},
	{
	  "items": {
		"additionalProperties": false,
		"properties": {
		  "author": {
			"type": "string"
		  },
		  "id": {
			"$ref": "#/definitions/zodObject/properties/comments/anyOf/0/items/properties/id"
		  },
		  "title": {
			"$ref": "#/definitions/zodObject/properties/comments/anyOf/0/items/properties/title"
		  }
		},
		"required": [
		  "id",
		  "title",
		  "author"
		],
		"type": "object"
	  },
	  "type": "array"
	}
  ]
}

Since we aren't actually bundling any definitions, these references don't resolve and we end up with an error like this.

We also fix this by naming and bundling all definitions generated, but it'll be so clunky. We'd end up with definitions named something like commentsGetPostCommentsResponses200

Hey guys! I'm having some issues when creating an endpoint on nestjs + ts-rest that receives a param and has versioning configured by nest have you guys ever faced these issues?

Example:

Contract route

 getIndustryTag: {
    method: 'GET',
    path: `/industry-tags/:uid`,
    responses: {
      200: ResponseIndustryTagModel.nullable(),
    },
    summary: 'Get an industry tag',
  },

Controller

@Controller({
  version: '1',
})
export class IndustryTagsController {
  constructor(private readonly industryTagsService: IndustryTagsService) {}

  @Api(server.route.getIndustryTag)
  async findOne(
    @ApiDecorator() { params: { uid } }: RouteShape['getIndustryTag']
  ) {  
        ....
    }

The end route for this would be http://localhost:3000/v1/industry-tags/uid-123 but since the contract route doesn't know about the versioning that was applied, I receive the string industry-tags has the param instead of the uid-123

Even if I apply the v1 to the contract path it will become v1/v1/industry-tags so it wouldn't help either

The only solution I can see working is managing the versioning inside the contract only and letting go of the nestjs versioning system, but I wanted to know if there are other options for this and if this is a known issue

Thanks!

Hi!

Figured I'd try to help out and contribute back.

It doesn't seem baseUrl is accessible in the api method. It may be missing as a type, or not a feature yet. I can look into that and open a PR.

I moved all the custom stuff to a Custom Client page to make it more apparent since I feel there will be many other people wanting to take advantage of this.

Thank you, and let me know what you think!

For cases where zod input and output types differ such as when using .default() or .transform(), we need to use the input type on the client-side.

const foo = z.object({ bar: z.string().default('bar') });
type input = z.input<typeof foo>; // { bar?: string | undefined }
type output = z.infer<typeof foo>; // { bar: string }

Hey, I've been using ts-rest for a few days and find it extremely well made! But I have quite a big issue.

@ApiDecorator is not working properly.

When hitting /media/:id with like /media/some-id it returns media instead of some-id

// .............

const m = initContract();

const mediaContract = m.router({
// ..........
  getMedia: {
    method: 'GET',
    path: '/:id',
    responses: { 200: m.response<any>(), },
    summary: 'get a media',
  },
})

const c = initContract();

export const contract = c.router({
 //..........
  media: mediaContract,
});

const s = initRouteContract(contract.media);
type ControllerShape = typeof s.controllerShape;
type RouteShape = typeof s.routeShapes;

@Controller('media')
export class MediaController implements ControllerShape {
  @Api(s.route.getMedia)
  async getMedia(@ApiDecorator() { params: { id } }: RouteShape['getMedia']) { 
    return id; // returns "media" instead of the ID
  }
}

Please provide an hotfix, I can't use the library anymore for now... because of this bug

EDIT : WORKAROUND FOR NOW : use the native @Param from NestJS :

@Api(s.route.getMedia)
// async getMedia(@ApiDecorator() { params: { id } }: RouteShape['getMedia']) {
async getMedia(@Param('id') id: string) {
  return id; // returns "some-id" correctly
}

@oliverbutler Sorry about this, I removed the exports from the package.json in the last PR and it seems like it broke something and I have no idea why, but you probably had it in there for the some valid reason. Without the exports in package.json I get this error in Next.js

No QueryClient set, use QueryClientProvider to set one

From some quick research it seems like this happens when different react-query versions are being used, but I could not observe that in my case so I dunno honestly 🤷‍♂️

Per discussion on Discord, this feature allows users to extract response types from a given Contract. This is particularly useful for backend services where you want to avoid implementing an interface.

I aimed to make this as non-intrusive as possible! All tests pass. Please read the modified Docs to get a feel for the changes/additions, and then you can look at client.ts to see the entry point of the implementation.

Here's a screenshot of how it works:

This is potentially a huge aspect of ts-rest, it would be awesome to document, possibly with some interactive examples how the lib works.

@ghoullier I'm happy to have you help out with this, mind that I'm not particularly considering any changes to the @ts-rest/open-api lib to be breaking until we release it on the docs 🤔

If you don't have time that's completely OK I can put it on the backlog!

@ts-rest/solid-query is 95% working, the only broken part is that the args attribute should be a callback so that solid js can react to changes to params/query params etc.

• Fix () -> args
• Fix data return type to make sure it's { status, body } just like the rest of ts-rest

I want to better explain the mental model, with some diagrams.

Contract initContract from @ts-rest/core

• Defined only on the front end, for an uncontrollable API
• Defined in a shared lib, used by both front and backend
• Defined by a shared npm module, for an internal or external API

^ To clarify and advertise that it isn't a full stack, all-or-nothing tech, it can be incrementally adopted and has no backend requirements.

Base client initClient from @ts-rest/core

• Is a simple wrapper around fetch, nothing more, it has a type-safe wrapper around it but the implementation is SERIOUSLY tiny
• Can be used for any framework, not restricted to @tanstack adapters

^ To clarify that you can use any framework, no limits. (#71 )

Other libs

• Adapters for first-class support with other libs, NOT REQUIRED

^ To clarify that you can use ts-rest even without a supported adapter e.g. Vue (#71 )

this works

const claims = c.router({
  getClaimsForApproval: {
    method: 'GET',
    path: `/partner/:partnerId/claims`,
    responses: { 200: c.response<{ id: string }[]>() },
    query: z.object({
      take: z.number().optional(),
      skip: z.number().optional(),
    }),
  }
});

export const claimServicePartnerApi = c.router({
  claims,
});

this doesn't work "path" becomes string

export const claimServicePartnerApi = c.router({
  claim: {
    getClaimsForApproval: {
      method: 'GET',
      path: `/partner/:partnerId/claims`,
      responses: { 200: c.response<{ id: string }[]>() },
      query: z.object({
        take: z.number().optional(),
        skip: z.number().optional(),
      }),
    }
 }
});

I think it's due to how I'm naïvely applying the Narrow helper, it probably should recursively go though the object...