feat(transport-commons): Ability to register routes with custom params

[vonagam]

Allows to add routes with some predetermined route params which are not placeholder based.

// context.params.route.some will be 'param' for '/some/path' 
app.routes.insert('/some/path', { service, params: { some: 'param' } });

[daffl]

Yep, can definitely see that being useful. I think we can also add it to the new service options (https://dove.docs.feathersjs.com/api/application.html#use-path-service-options) to make it more integrated:

app.use('/messages', new MyService(), {
  methods: [ 'get', 'doSomething' ],
  events: [ 'something' ],
  params: { something: 'here' }
});

[vonagam]

One question that i had when looking through code:

Is it possible to register same instance of a service on different routes? This line makes me think that this possibility was thought about at some point.

If yes then it means that you can pass server options only during first use call since wrapService does not support having multiple settings stored. So if you pass options second time they will be silently ignored which is a bug.

If no then shouldn't wrapService throw an error (instead of returning) when it receives already wrapped service?

[daffl]

Great, thank you! This looks good to me.

Good point about re-using the options. Can we put up a test for this to see what would be a good way to go about that? The goal was basically to

• Re-use existing services (but possibly with different options when passed)
• Have custom or plugin services provide their own options (e.g. custom methods and events) without somebody having to explicitly define them on registration

[vonagam]

Hm... if plugins will provide their own options using SERVICE symbol then it means that options provided on a registration will be ignored even on first one. But I think that this is a separate issue and should be handled in another PR.

Other question:
Are there any plans to use router from transport-commons for express? Right now koa and socket transports use the router, but not express, so this change will be useful for them but not for express.

[daffl]

You're right, the service options should be a different PR/issue.

The problem with changing the router in Express is that things like custom service middleware (and any other middleware matching Express routes which are not compatible with this router) won't work anymore.