IMPORTANT: Feathers 4 and later has built-in TypeScript support. Please see the docs for more information

http://docs.feathersjs.com/frameworks/angular2.html Now the demo uses

const feathers = require('feathers/client');
const socketio = require('feathers-socketio/client');
const io = require('socket.io-client');
const localstorage = require('feathers-localstorage');
const hooks = require('feathers-hooks');
const rest = require('feathers-rest/client');
const authentication = require('feathers-authentication/client');

Please support TypeScript definitions to use import!

This is real issue that I've recently had, but I guess this concerns the framework in whole. I think that it is natural for Feathers services to be asynchronously initialized. They can pick their configuration from asynchronous sources, or it can be something else.

In most cases synchronous application initialization is presumed, but I've encountered design problems when started using Sequelize.

While Mongoose does some good job on accumulating promises inside for initialization actions (connection, index creation), so queries are automatically chained to initial promises, Sequelize does nothing like that, e.g. when sync() is called.

I would expect that SQL database is ready at the moment when web server has been started, but when the application is defined in synchronous manner, it will not. And this is what happens with typical Feathers setup. In some cases async initialization may take several ms, in other cases it may take seconds, while the server will pollute logs with errors that should have been never happen normally.

Another problem is error handling. If there are uncaught errors during async service initialization, the reasonable move would be to halt app initialization and catch errors in a single place.

Here's a small example that explains the idea and is based on the structure proposed by Feathers generator template.

app.js:

const app = require('feathers')();

// THIS!
app.set('feathersServicePromises', []);

app
.use(require('body-parser').json())
.configure(require('feathers-hooks'))
.configure(require('feathers-rest'))
.configure(require('./middleware'))
.configure(require('./services'));

// THIS!
Promise.all(app.get('feathersServicePromises'))
.then(() => app.listen(3000), console.error);

services/index.js:

module.exports = () => {
    const app = this;

    app
    .configure(require('./foo-async-service')
    .configure(require('./bar-async-service')
    .configure(require('./baz-sync-service')
};

services/foo-async-service.js:

const sequelize = require('./common/sequelize');

module.exports = () => {
    const app = this;
    const fooModel = sequelize.model('foo');

    // AND THIS!
    const initPromise = fooModel.sync();
    app.get('feathersServicePromises').push(initPromise);

    app.use('/foo', require('feathers-sequelize')({ Model: fooModel  }));
    app.service('/foo');
};

The places of interest here are initPromise and Promise.all(...). It would be convenient to just return initPromise from service function, like it is done in hooks. And Promise.all(...) could probably be lazily executed with app object toPromise() method or promise getter property. So it could be

module.exports = () => {
    ...
    return fooModel.sync();
};

in service function, and

app
...
.configure(require('./services'))
.promise
.then(() => app.listen(3000), console.error);

in entry point.

I suppose that the pattern I've used for async initialization is already simple and clean, but it would be great if the framework would take this job.

My suggestion is to place this feature under consideration.

I would appreciate any thoughts on the subject.

Right now we have full CRUD action for services but do not have GUI. It would be great if we have simple web application for user input. Maybe via tutorial or via code auto generator. Feather will be crazy seed for any project :dancer:

I am consolidating all the individual issues and discussions here:

This is a proposed special attribute that allows you to fuzzy match a property. Possibly even multiple properties and/or nested documents.

Suggested syntax:

name: {
  $search: ['alice', 'Alice', 'bo', /$bob/i]
}

Following similar syntax to our other special query filters, this would allow you to filter by a singular value, multiple values (treated like an or) and/or regular expressions directly.

Service Adapter Completion

• [ ] NeDB
• [ ] MongoDB
• [ ] Mongoose
• [ ] Sequelize
• [ ] Knex
• [ ] Waterline
• [ ] RethinkDB
• [ ] Memory
• [ ] Localstorage
• [ ] LevelUp
• [ ] Blob?? (maybe to support fuzzy matching filenames?)

IMPORTANT: Feathers 4 and later comes with built-in TypeScript support. Please see the docs for more information

Propose switching to TypeScript

In another thread, @marshallswain asked what the benefits are, and nobody really answered.

TypeScript has already reached the StackOverflow volume of CoffeeScript and is getting close to the number of GitHub repos. I know that is subjective, but if you think about the relatively small amount of time TypeScript has been around it is pretty impressive. Someone asked above about the value TypeScript would provide the core team. Here are the benefits as I see them, even for JavaScript Unicorns.

1. It is just sugar on top of JavaScript, so while it is a few extra keystrokes, you really won't notice much difference
2. All of your existing ES2015+ knowledge moves over with you, you can use as much or little of the extra features as you want.
3. You get a great amount of type safety for those extra keystrokes. Meaning it will tell you immediately if you are passing the wrong number or kind of parameters to a function. It might slow you down at the very beginning, but after a few days your velocity will actually be higher than before you used it, because you find a lot of mistakes before you even try to compile.
4. If you write the code for this project in TypeScript, you get completely accurate declarations for the community for free. It's just a compiler switch at that point and where you want to output them. This will increase your user base greatly and will probably add some contributors as well. This brings Angular support with no extra effort. If you don't know already, Google mothballed AtScript and decided to write Angular 2+ in TypeScript.
5. You can add TypeScript gradually, since TypeScript is just a super-set of JavaScript, every JavaScript file is TypeScript already, and the compiler will happily compile it along with TypeScript in most cases.
6. This isn't just code completion, the compiler is statically analyzing your project for Type Errors the entire time. Every experience I have read about that has converted JS projects says it detected bugs they didn't even know they had.
7. With projects like TypeDoc, you get very easy API documentation with types included, but not required.
8. Consumers can still choose to use regular ES5 and should not even care that you wrote it in TypeScript.
9. You can get features like unions, where you can say type switcher = "on" | "off" | "disabled", then you can say in your function changeLightStatus(newState: switcher), now if I try to pass "enabled" it will immediately complain that "enabled" is not a valid option and that I must specify "on", "off" or disabled. That is pretty awesome.
10. You will make a lot of people happier than you already have with this amazing project, that I really want to use, but won't until there is proper TS support.

To be clear, this isn't meant to be a "which is better" type of discussion. There is nothing wrong with the code you have, it is both beautiful and elegant. I am trying to make the case, that you will get a lot of added value for very little effort.

I know this is bordering on a dead horse, I would just ask that you please do some research to see if it is a good fit for you and your team. There is a large group of us passing on this, because once you start using it, going back to being without it seems archaic. Again, there is nothing wrong with what you are doing now, that archaic feeling is only something you experience after using it for awhile. I am describing the feeling, not your code base or any other.

I would definitely appreciate your careful consideration and I know myself and others in the community would be willing to help.

So I have developed an app with the feathers framework. I have a hook attached to a database service that I want to access data from another service. Is this possible, and easy? I want that service to be able to access several neDB files. How do I do this?

'use strict';

module.exports = function(options) {
  return function(hook) {

    // access other db files here and get data

    hook.data = {
        putDataHere: newData
    };
  };
};

From @krthr on August 30, 2018 23:4

Steps to reproduce

• [ ] populateAccessToken functions isn't getting the accessToken token property.

Expected behavior

Login and create a new resource from the client.

Actual behavior

Login and getting and error when i try to create a new resource:

Uncaught (in promise) TypeError: Cannot convert undefined or null to object
    at Function.assign (<anonymous>)
    at Object.eval (populate-access-token.js?39da:9)
    at promise.then.hookObject (hooks.js?8408:142)
(anonymous) @ populate-access-token.js?39da:9
promise.then.hookObject @ hooks.js?8408:142
...

Module versions (especially the part that's not working):

• "@feathersjs/authentication-client": "1.0.3"
• "@feathersjs/feathers": "3.2.0"
• "@feathersjs/socketio-client": "1.1.1"

NodeJS version: 8.9.4 Operating System: Windows 10

Copied from original issue: feathersjs/authentication-client#108

Steps to reproduce

I'm experiencing an issue where frequently when performing a service call an authenticated user will seemingly lose authentication for a second, causing the service call to fail. After that it looks like they are re-authenticated, but that one service call is lost. The server logs show a "No auth token" error on the before hook of whatever service was called when this occurs. At first I thought the problem was caused by calling other services within a hook and not passing the authentication params to them, but looking at the logs the server produces this error happens even when the only hook on the called service is authenticate('jwt').

I'm not sure what the relevant code that could be causing this issue is. Here is what my authentication.js looks like:

const authentication = require('@feathersjs/authentication');
const jwt = require('@feathersjs/authentication-jwt');
const local = require('@feathersjs/authentication-local');
const PasswordValidator = require('password-validator');

module.exports = function(app) {
  const config = app.get('authentication');

  // Setup password validator if a policy is defined
  if (config.passwordPolicy) {
    let validator
    app.getPasswordPolicy = function () {
      // Create on first access, should not be done outside a function because the app has not yet been correctly initialized
      if (validator) return validator
      let { minLength, maxLength, noSpaces } = config.passwordPolicy

      validator = new PasswordValidator()
      if (minLength) validator.is().min(minLength)
      if (maxLength) validator.is().max(maxLength)
      if (noSpaces) validator.not().spaces()
      
      return validator
    }
  }

  // Set up authentication with the secret
  app.configure(authentication(config));
  app.configure(jwt());
  app.configure(local());

  // The `authentication` service is used to create a JWT.
  // The before `create` hook registers strategies that can be used
  // to create a new valid JWT (e.g. local or oauth2)
  app.service('authentication').hooks({
    before: {
      create: [
        authentication.hooks.authenticate(config.strategies),
      ],
      remove: [authentication.hooks.authenticate('jwt')],
    },
    after: {
      create: [
        context => {
          //send data with auth response
          context.result.userId = context.params.user._id;
        }
      ]
    }
  });
};

Here is my channels.js:

const logger = require('winston');

module.exports = function(app) {
  if (typeof app.channel !== 'function') {
    // If no real-time functionality has been configured just return
    return;
  }

  app.on('connection', connection => {
    // On a new real-time connection, add it to the anonymous channel
    app.channel('anonymous').join(connection);
  });

  app.on('logout', connection => {
    //When logging out, leave all channels before joining anonymous channel
    app.channel(app.channels).leave(connection);
    app.channel('anonymous').join(connection);
    logger.log('info', 'logout');
  });

  app.on('login', (authResult, { connection }) => {
    // connection can be undefined if there is no
    // real-time connection, e.g. when logging in via REST
    if (connection) {
      // Obtain the logged in user from the connection
      const { user } = connection;

      // The connection is no longer anonymous, remove it
      app.channel('anonymous').leave(connection);

      // Add it to the authenticated user channel
      app.channel('authenticated').join(connection);
      logger.log('info', 'login');

      // User joins their own private channel
      //logger.log('info', typeof user._id === 'string')
      app.channel(`user/${user._id.toString()}`).join(connection);

      //if the user is a member of any chatrooms, join their channel
      app
        .service('rooms')
        .find({
          query: {
            $limit: 25,
            rmembers: {
              $in: [user._id]
            }
          },
          user: user
        })
        .then(roomArray => {
          roomArray.data.forEach(room => {
            app.channel(`rooms/${room._id.toString()}`).join(connection);
          });
        });
    }
  });

  // When a user is removed, make all their connections leave every channel
  app.service('users').on('removed', user => {
    app.channel(app.channels).leave(connection => {
      return user._id === connection.user._id;
    });
  });

  // Publish user create events to all authenticated users
  app.service('users').publish('created', (data, context) => {
    return app.channel('authenticated');
  });

  // Publish user updated events to that user
  app.service('users').publish('updated', (data, context) => {
    return app.channel(`user/${data._id}`);
  });

  // Publish user patched events to that user
  app.service('users').publish('patched', (data, context) => {
    return app.channel(`user/${data._id}`);
  });

  // Publish all messages and rooms service events only to its room channel
  app.service('messages').publish((data, context) => {
    //logger.log('info', 'message sent');
    return app.channel(`rooms/${data.roomId}`);
  });

  app.service('rooms').publish((result, context) => {
    return app.channel(`rooms/${result._id}`);
  });

  //Publish challenge completion and power rewards to the required user
  app.service('user-challenges').publish((result, context) => {
    return app.channel(`user/${result.userId}`);
  });

  app.service('user-powers').publish((result, context) => {
    return app.channel(`user/${result.userId}`);
  });

  // Publish room-activity create events only to its room channel
  app.service('room-activity').publish('created', (data, context) => {
    return app.channel(`rooms/${data.roomId}`);
  });

  // Publish notifications to their recipients
  app.service('notifications').publish('created', (data, context) => {
    return context.data.map(user => {
      return app.channel(`user/${user}`);
    })
  });
};

Here is what I have on the client side in regards to authentication:

this.socket = io(...); //set to ip address of server
	this.app = feathers()
		.configure(socketio(this.socket, { timeout: 10000 }))
		.configure(
			authentication({
				storage: AsyncStorage
			})
		);

...

login(username, password) {
	this.app
		.authenticate({
			strategy: "local",
			uname: username,
			pword: password
		})
		.then(
			action("authSuccess", user => {
				// User is authenticated
				this.isAuthenticated = true;
				this.userId = user.userId;
			})
		)
		.catch(error => alert(error.message));
}

If there's any other code you think may be causing the problem and you'd like to look at just let me know.

Expected behavior

The service call should complete successfully.

Actual behavior

The service call fails and returns a "No auth token" error.

System configuration

Module versions (especially the part that's not working): Server: @feathersjs/authentication: 2.1.5 @feathersjs/authentication-jwt: 2.0.1 @feathersjs/authentication-local: 1.2.1 @feathersjs/configuration: 1.0.2 @feathersjs/errors: 3.3.0 @feathersjs/express: 1.2.2 @feathersjs/feathers: 3.1.5 @feathersjs/socketio: 3.2.1 Client: @feathersjs/authentication-client: 1.0.2 @feathersjs/client: 3.4.5 @feathersjs/feathers: 3.1.5 @feathersjs/socketio-client: 1.1.0

NodeJS version: 9.11.1

React Native Version: 0.55.4

A Feathers API is really easy to talk to. A native iOS client would be awesome and @corymsmith has done some prototyping here. It should behave similar to the Feathers client and feel familiar to people coming from the JS client. The things it should support:

• Service communication over REST similar to feathers-rest/client
• Service communication over Websockets similar to feathers-socket-commons/client
• Authentication similar to feathers-authentication/client
  • An authenticate method that authenticates against the server and stores the JWT somewhere
  • A logout method that destroys the stored JWT
  • See docs for more info on the auth flow.
• Hooks similar to feathers-hooks
  • Ability to register before and after hook chains to mutate data or query params

feathers-client is a consolidation module for all the modules above. This is so that we can create a standalone bundle for people without JS module loaders. I don't think we need to do this for iOS. These client modules should all be bundled inside the one iOS client.

We have a repository with some initial code set up for this if anyone wants to tackle it.

This issue consolidates the work from feathersjs/schema and the discussion from https://github.com/feathersjs/schema/issues/20 into an up to date proposal in the main repository since I think for now it makes the most sense to include the @feathersjs/schema here (with the option to turn it into a standalone module later once it has been used for a bit).

Problem

A very common problem we are seeing in web application development at the moment, especially in the NodeJS world, is that data model definitions are duplicated in many different places, be it ORM models, JSON schema validators, Swagger/OpenAPI specifications, TypeScript type definitions or GraphQL schemas. It is difficult to keep them synchronized and any new protocol or database is probably going to need the same work done again.

You can find converters from almost any specific format to any other format on npm but there are many challenges from relying on a compilation step (generating duplicate code that doesn't really have to exist in the first place) to only covering a small subset of functionality. It also appeared a majority of those modules is no longer actively maintained. ORMs are trying to address the challenge by locking you into their way of doing things with database or ORM specific idiosynchrasies dictating how flexible you can be in defining your model.

Feathers schema

Feathers schema provides a common schema definition format for JavaScript and TypeScript that allows to target different formats like GraphQL, JSON schema (Swagger/OpenApi), SQL tables, validations and more with a single definition. Similar to how Feathers services allow different transport mechanisms to access their API without having to change your application code, schemas are Feathers answer to address the ever expanding list of data schema definition and validation formats.

It does not only address the definition of data types but also how to resolve them within the context of your application. This is a different approach to most ORMs where you define your data model based on the database (or other ORM specific convention). Some examples where schemas are useful:

• Ability to add read- and write permissions on the property level
• Complex validations and type conversions
• Shared model definition types between the client and server (when using TypeScript)
• Associations and loader optimizations
• Query string conversion, validation (no more type mismatches) and protections
• Automatic API docs

How it works

@feathersjs/schema uses JSON schema as the main definition format with the addition of property resolvers. Resolvers are functions that are called with the application context and return the actual value of a property. This can be anything from the user associated to a message to the hashed password that should be stored in the database.

Schema definitions

import { schema } from '@feathersjs/schema';

const UserSchema = schema({
  type: 'object',
  required: [ 'email', 'password' ],
  additionalProperties: false,
  properties: {
    id: { type: 'number' },
    email: { type: 'email' },
    password: {
      type: 'string',
      minLength: 8
    }
  }
});

const MessageSchema = schema({
  type: 'object',
  required: [ 'text' ],
  additionalProperties: false,
  properties: {
    id: { type: 'number' },
    userId: { type: 'number' },
    text: {
      type: 'string',
      maxLength: 400
    }
  }
});

// This defines a `data` schema (for `create`, `update` and `patch`)
// based on UserSchema that hashes the password before putting it into the db
const UserDataSchema = schema(UserSchema, {
  properties: {
    password: {
      resolve (password) {
        return hashPassword(password);
      }
    }
  }
});

// A new schema based on MessageSchema that includes the associated user
const MessageResultSchema = schema(MessageSchema, {
  properties: {
    user: {
      resolve (value, message, context) {
        const { app, params } = context;

        return app.service('users').get(message.userId, params);
      }
    }
  }
});

TypeScript

TypeScript types can be inferred from schema definitions. This is where to me TypeScript finally is starting to make real sense 😸 You get type definitions, dynamic validations and resolvers all in one place:

import { schema, Infer } from '@feathersjs/schema';

const UserSchema = schema({
  type: 'object',
  required: [ 'email', 'password' ],
  additionalProperties: false,
  properties: {
    id: { type: 'number' },
    email: { type: 'string' },
    password: {
      type: 'string',
      minLength: 8
    }
  }
} as const);

type User = Infer<typeof UserSchema>;

const user = UserSchema.resolve({
  email: '[email protected]',
  password: 'supersecret'
});

Both the User type and user variable will have a type of the following interface:

type User = {
  id?: number;
  email: string;
  password: string;
}

Using schemas with Feathers

In a Feathers application schemas can be passed when registering a service via the options introduced in v5. Different schemas can be passed for validating data and params.query as well as resolving the result object returned to the client.

import { feathers } from '@feathersjs/feathers';

const app = feathers();

// One schema for everything
app.use('/messages', new MessageService(), {
  schema: MessageSchema
});

// Different schema for `result`, `data` and `query`
app.use('/messages', new MessageService(), {
  schema: {
    result: MessageResultSchema,
    data: MessageDataSchema,
    query: MessageQuerySchema
  }
});

// With override for a specific method
app.use('/messages', new MessageService(), {
  schema: {
    result: MessageResultSchema,
    data: MessageDataSchema,
    query: MessageQuerySchema,
    methods: {
      patch: {
        data: MessagePatchSchema
      }
    }
  }
});

Feedback wanted

Development is currently happening in the schema branch and will eventually be moved to dove. I will start adding documentation in the Dove API docs section once a pre-release PR is ready. Many thanks already to the feedback to @DaddyWarbucks, @DesignByOnyx and @mrfrase3, please continue to challenge my assumptions if you see anything else that this proposal is missing 😄

Currently, once the app is running, it's pretty difficult to unregister Feathers services and hooks.

We would like to be able to support unregistering all event handlers associated with a route, so we can recreate and re-register them while the server keeps running. If we do this right, it will enable people to use hot reloading techniques such as Webpack's Hot Module Replacement with their Feathers services and hooks.

API suggested by @daffl in Slack:

app.service('/myservice',  null)

would completely undo the effects of

app.use('/myservice', myservice)

...and thus allow us to use HMR like this:

services/myservice/index.js

'use strict';

let app; // hang on to the app object
module.exports = function(){
  app = this;
  register()
};

function register() {
  // re-require on every invocation to facilitate HMR
  // `require` caches modules once loaded, so second require is fast.
  const hooks = require('./hooks');
  const Service = require('./service');
  app.use('/myservice', new Service());
  const service = app.service('/myservice');
  service.before(hooks.before);
  service.after(hooks.after);
}

function unregister() {
  app.service('/myservice', null);
}

if (module.hot) {
  module.hot.accept(['./hooks', './service'], function(){
    unregister(); // unregister the old service and hooks
    register(); // ..and register the new ones. 
  })
}

// not sure if it's useful to keep this next line...  modules referencing 
// `Service` would need to make sure they get the new one somehow...
// module.exports.Service = Service;

{
    "total": 2,
    "limit": 10,
    "skip": 0,
    "data": [
        {
            "_id": "62f4d8cf2994171830bf2e79",
            "trailerNumber": {
                "_id": "62f4d8cf2994171830bf2e65",
                "licenceStatus": true,
                "deleted": true
            }
        },{
            "_id": "62f4d9642994171830bf34d2",
            "trailerNumber": {
                "_id": "62f4d9642994171830bf34be",
                "licenceStatus": true,
                "deleted": false
            }
        }
    ]
}

i try using this query

ctx.params.query.$populate = [{
    path: 'trailerNumber',
    match: { deleted: false },
}]

it will return null for trailerNumber deleted: true, not removed the data. i don't want using aggregate

Steps to reproduce

In an empty repo run npx @feathersjs/cli@pre generate app and choose mostly defaults, use yarn as package manager

- Do you want to use JavaScript or TypeScript? TypeScript
- What is the name of your application? feathers-dove
- Write a short description 
- Which HTTP framework do you want to use? KoaJS 
- What APIs do you want to offer? HTTP (REST), Real-time
- Which package manager are you using? Yarn
- What is your preferred schema (model) definition format? TypeBox (recommended)
- Which database are you connecting to? Other databases can be added at any time PostgreSQL
- Enter your database connection string postgres://docker:docker@db-dev:5432/docker_dev_data
- Which authentication methods do you want to use? Other methods and providers can be added at any time. Email + Password

Expected behavior

Yarn is used to install

Actual behavior

Everything was installed via npm and I ended up with a package-lock.json

System configuration

Tell us about the applicable parts of your setup.

running npm info @feathersjs/cli@pre results in

@feathersjs/[email protected] | MIT | deps: 5 | versions: 70
The command line interface for creating Feathers applications
https://feathersjs.com

keywords: feathers, feathers-plugin

bin: feathers

dist
.tarball: https://registry.npmjs.org/@feathersjs/cli/-/cli-5.0.0-pre.34.tgz
.shasum: 50752e2f709ed44bc2f4d5c63a36013e2a4a7c5c
.integrity: sha512-lSLidOtFErvs2tLiyVH24G4RyZfDsbJlEmCLU39wqwlPSUOaYcsxYDyOyJmP0dDrzvcRODrrbB4LdmlRo736cQ==
.unpackedSize: 284.7 kB

dependencies:
@feathershq/pinion: ^0.3.5 chalk: ^4.0.1              commander: ^9.4.1          lodash: ^4.17.21           prettier: ^2.8.0           

maintainers:
- daffl <[email protected]>
- marshallswain <[email protected]>
- alexisabril <[email protected]>

dist-tags:
latest: 4.8.0      pre: 5.0.0-pre.34  

published a week ago by daffl <[email protected]>

Node v16.15.1

OSX Monterey 12.6.1

Hi dear feathers team Recently I'm facing some security problem reports from npm (audit) with "jsonwebtoken" package.

npm audit report

jsonwebtoken  <=8.5.1
Severity: high
jsonwebtoken has insecure input validation in jwt.verify function - https://github.com/advisories/GHSA-27h2-hvpr-p74q
jsonwebtoken's insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC - https://github.com/advisories/GHSA-hjrf-2m68-5959
jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify() - https://github.com/advisories/GHSA-qwph-4952-7xr6
jsonwebtoken unrestricted key type could lead to legacy keys usage  - https://github.com/advisories/GHSA-8cf7-32gw-wr33
No fix available
node_modules/jsonwebtoken
  @feathersjs/authentication  *
  Depends on vulnerable versions of jsonwebtoken
  node_modules/@feathersjs/authentication
    @feathersjs/authentication-client  >=4.3.3
    Depends on vulnerable versions of @feathersjs/authentication
    node_modules/@feathersjs/authentication-client
    @feathersjs/authentication-local  >=4.3.3
    Depends on vulnerable versions of @feathersjs/authentication
    node_modules/@feathersjs/authentication-local
    @feathersjs/authentication-oauth  *
    Depends on vulnerable versions of @feathersjs/authentication
    Depends on vulnerable versions of @feathersjs/express
    Depends on vulnerable versions of @feathersjs/koa
    node_modules/@feathersjs/authentication-oauth
    @feathersjs/express  >=5.0.0-beta.0
    Depends on vulnerable versions of @feathersjs/authentication
    node_modules/@feathersjs/express
    @feathersjs/koa  *
    Depends on vulnerable versions of @feathersjs/authentication
    node_modules/@feathersjs/koa

7 high severity vulnerabilities

I think upgrading to jsonwebtoken version 9.0.0 will solve the problem

I was breaking my head over some strange errors, "params": { "additionalProperty": "email" }, "message": "must NOT have additional properties"}

I was tarting to blame ... until, on Discord @marshallswain gave me the tip, in my "defense", just 5 minutes after I found it myself ;))): I was applying hooks from one service to another service... oops.

The suggestion is now to introduce in the cli a constant servicePath, one place change if you are cut and pasting the code to create a new service manually:

const servicePath = 'users' // the suggestion

export const user = async (app: Application) => {
  app.use(servicePath, new UserService(getOptions(app)), {
    methods: ['find', 'get', 'create', 'update', 'patch', 'remove'],
    events: []
  })

  app.service(servicePath).hooks(hooks)

The disadvantage is that it is slightly less nice to the eye... but well...just an idea ;)

Having the deep outline makes it much easier to navigate the massive TypeBox API. Mobile devices only see a short table of contents, but for larger screens, it’s much easier to see what’s available when the sidebar shows the full tree. Also, there’s so much in the document that it’s easy to get lost. The deep outline solves that.