Bundling Typed Client

[b-steel]

We're currently running V4 for our API and I've been looking into making the change to V5. One of the things that I'm interested in is the typed client, but I have a couple questions about it that I'm having a hard time answering.

Setup

Setup blank app directly from the docs
npm create feathers@latest feathers-chat
Answer things the same as in the docs

Run cd feathers-chat && npm run bundle:client which indeed creates a bundled package at ./public/feathers-chat-0.0.0.tgz

Question1: Extra Dependencies

If I unzip ./public/feathers-chat-0.0.0.tgz I get a package folder with lib/ and package.json. Looking at the /package.json I see that all the dependencies are included in there, but it seems to me that the client should not depend on things like knex and winston and some of the @feathersjs/package packages. If I install the client in some other project as advertised in the docs with npm install https://myapp.com/appname-x.x.x.tgz (I ran npm install ../feathers-chat/public/feathers-chat-0.0.0.tgz in an adjacent project) I can confirm that all those dependencies were installed via npm why knex etc.

I can manually remove the extraneous dependencies, but if I re-bundle the client I'll have to do that again. So it seems I'd need to write some sort of tooling to automate this.

So my question is, am I missing something here or is this just what's available out of the box. I totally understand if it's the latter, but I want to make sure I'm not missing something here before I start building a custom script to fix this.

Question 2: Separate Package

Additionally we've got everything in a monorepo so I think I'll have to write a script that bundles the client, (maybe strips out some deps) and then stuffs it into it's own package in our /packages/ folder to be used by other apps. Curious if there's any other way to extract the client to be a separate package instead of being part of the main feathers app and then bundling it off. This is kinda a vague question, but mostly curious if you'd had anyone else with a similar issue and could point me in a certain direction.

Thanks for any insight you can provide.

[daffl]

These are good questions and things I noticed as well.

1. Unfortunately the extra dependencies are needed because we can't tell which types from a dependency is re-exported to the client.
2. I think this might be the option to go with in the future. I believe there is a better way of inferring the client application interface hopefully with more flexibility. I actually ended up doing the same thing for an internal project. It still uses the application types by importing them (as relative paths) but only has the dependencies you need. I don't think there is a way to define environment specific dependencies but it would be nice.

[b-steel]

Thank you for the clarification, I'll experiment with ways to achieve a somewhat extracted client (or at least the types) so that I can have the types in a separate package.

[nmccrea]

I just went through this process recently for the exact same reasons. The currently-documented approach to the typed client left us with really huge front-end builds bloated with unnecessary back-end dependencies.

Our solution was indeed to break the typed client out into a separate package in our monorepo. It was a bit tricky to figure out how to make it work in a satisfactory way but it's working really nicely now. We've preserved all the benefits of the typed client. We've broken the dependency linkage so that our front-end is no longer bloated. And it plays nicely with our development environment and intellisense.

Figured I'd share our approach:

The typed client source must import types (i.e. service types, TypeBox schema types, etc) from the server source code. However, if we ensure that the server files which define these types do not themselves import from any of the server-specific dependencies, those server-specific modules will not be needed for the typed client to build successfully.

Keeping these type definitions isolated from unnecessary dependencies in this way is the key. With Feathers it is quite easy to organize the server so that the types originate in files which only import from common Feathers packages that are also natural front-end dependencies.

The typed client itself is implemented exactly as documented by Feathers, with the only difference being that it "reaches across" to the adjacent server package in the monorepo using relative imports in order to get the types it needs. Turns out this is fine.

Now, for us there is nothing other than types that actually need to be imported from the server. This means that when the typed client is built, we can configure tsconfig to emit only declaration files for those server source files. The compiled JS is just a small module that doesn't have anything from the server. The typed client's build output now has exactly what we want: A type-safe client implementation, declaration files for the canonical types that the front-end code can use, and zero unnecessary dependencies.

Because of the build step, the compile-time dependency on the server source files is foregone. The user of the typed client (e.g. front-end code) can now get all the benefits of using the types exposed in the typed client while being completely isolated from the server package.

Here are the caveats from our experience:

• The requirement to ensure that the types originate in files that never import the wrong things may be a little error prone.
• Any time the type definitions are modified in the server code, the typed client package must be re-built in order for the changes to be accessible to the front-end code. This is just a matter of running tsc and we have an NPM script that does this trivially.
• However, each time we rebuild the typed client, we find that our development environment loses track of things in intellisense. This requires restarting the TypeScript server in our editor, which is also a matter of a couple keystrokes.
• I do think this will only work in a monorepo. It's the relative imports from the server code that allow the typed client to use those types without needing the server as a node dependency.

[mdartic]

Hi,

For us, we build the typed client with vite and a specific config. By using the .shared.ts files correctly, we get a pretty small client.
This make a new package in our monorepo, that will be used in other packages.

Then, in our package sdk (the typed client, previously built by vite), we add a package.json with dependencies.
The feathers one are @feathersjs/authentication-client and @feathersjs/feathers only.

When we are in dev, we use the script npm run client:bundle:watch to regenerate the client when we touch the API files.
Sometimes we need to refresh our frontend, but it is most of the time up to date.

We have the same caveats for the IDE de-synchronization after the typed client has been regenerated.

Hope it could help