So @harangue has pretty much implemented a large set of the Feathers Typescript definitions already in https://gist.github.com/harangue/9d4ed79118e2656f5e3d2d699296ed36 we just need someone to review and potentially finalize them and submit them into the TypeScript definitions repository.

I am going to make this part of the Auk release which will land before the end of the year. If nobody steps up until then this issue will be closed for good and there will be no official TypeScript support or further discussion about this other than a pull request for the whole thing.

If their quality is good you should consider bundling the definitions with Feathers. I think a lot of people would want to avoid using a secondary package manager as much as possible.

They'd be installable via npm i @types/feathers. You don't need stuff like typings any longer.

I thought you just add them to https://github.com/DefinitelyTyped/DefinitelyTyped. Whatever is the normal way of doing this. If we add them to the core repo the other plugin repositories probably need definitions added accordingly.

From the DefinitelyTyped FAQ:

The types-2.0 branch is automatically published to the @types scope on NPM thanks to types-publisher. This usually happens within an hour of changes being merged.

Didn't know that. So adding them to DefinitelyTyped would suffice.

Ah, JS. You're gone for a month or two and the ecosystem evolves :smile:

Sorry that there's been radio silence about this on my end for so long. I just released another revision of the gist today that fixes some issue I'd had with the old typings. I'm finally able to start working with Feathers again on one of my projects, and I expect to be adding typings at the very least for the modules I find myself using.

The definition as it exists in the gist is ready to be submitted to Definitely Typed except for 1) typings tests (just need to pull some examples from the Feathers docs) and 2) JS Doc annotations (which would be nice for intellisense, but are not essential).

Technically the hook typings should be extracted to feathers-hooks as well. Extending typings here gets a little messy however, as uberproto has some mixin patterns that are a little challenging to replicate with static types.

Good to have you back @harangue. I think we can leave the hook typings in here for now since we are planning to make hooks part of core (see #408). Also the typings might need to be updated with the new .hooks method as described in https://blog.feathersjs.com/feathers-application-and-error-hooks-7a5982e70024 (not yet documented, working on it :).

@harangue when do you think you will be submitting your types to definitely typed?

Hey everyone, really cool to see TypeScript defs coming along. @harangue, what's your recommendation for importing feathers in conjunction with the defs in your gist? They aren't exporting namespaces that match the feathers libraries, so import ... from 'feathers' throws an error.

Hey @subvertallchris, you can use

import * as feathers from 'feathers';`

or

import feathers = require('feathers');

they're equivalent. :) Just when I thought I was getting time for Feathers again I got caught up in other stuff, but I'm hoping to have these definitions fleshed out completely by the new year.

@j2L4e Your TS generator fork seems to be 404'ing ? Any news on this? Also, @harangue how are you getting on? I am really keen to see this land and am happy to help the implementation of TS definition files, a fork with a feathers generate --ts flag to make the cli play with typescript nicely or docs. Let me know.

It was hard to maintain, worked properly for mysql and local auth only and generator-feathers will be obsolete soon anyway. So I scrapped it.

Eagerly waiting for a release of the new cli

Am 19. Dezember 2016 14:41:42 MEZ, schrieb georgeedwards notifications@github.com:

@j2L4e Your TS generator fork seems to be 404'ing ? Any news on this?
Also, @harangue how are you getting on? I am really keen to see this
land and am happy to help the implementation of TS definition files, a
fork with a feathers generate --ts flag to make the cli play with
typescript nicely or docs. Let me know.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/feathersjs/feathers/issues/381#issuecomment-267966376

Is there anyone still working on this issue? I would very much like to use this project with Typescript

Hello everyone

I'm happy to say: _It's almost done._ 😄
I have made many forks in FeatherjsOrg and write definitions by repo. And you can see this samples using feathersjs with the best of typescript definitions

Feathers+Nodejs+Typescript
FeathersClient+Aurelia+Typescript

[yes, it's support ESNext, Commonjs, AMD and global modules to client chunks]

The aurelia sample gives you clues how to work with angular2. These repositories have many details how typescript can be useful to give a live documentation about

I will do PRs soon, but you can see, make questions and give me feedbacks. 👌?

Fork wih definitions:

• feathers-hooks
• feathers-primus
• feathers-socketio
• feathers-rest
• feathers-authentication-client
• feathers-client
• feathers

I had a little work, but I love feathers and typescript

that's all relative links

I fixed the links.

@AbraaoAlves This looks great, thank you! I was just about to write a sulky comment and close the issue and I'm glad you commented first 😉 Looking forward to seeing the pull requests!

Good man @AbraaoAlves !

@AbraaoAlves I just wanted to say thanks so much, this is a huge help for me! I can't believe you came through at the last moment

@AbraaoAlves I am having trouble actually using any of your definitions. When I install the packages in the package.json such as

"feathers-errors": "^2.5.0",

"feathers-authentication": "^0.7.12",

"feathers-configuration": "^0.3.3",

"feathers": "https://[email protected]/AbraaoAlves/feathers.git#definition",

"feathers-hooks": "git://github.com/AbraaoAlves/feathers-hooks.git#definition",

"feathers-mongoose": "^3.6.2",

"feathers-rest": "git://github.com/AbraaoAlves/feathers-rest.git#definition",

"feathers-socketio": "git://github.com/AbraaoAlves/feathers-socketio.git#definition"`

So when I attempt to use it in a TypeScript file such as:

import * as feathers from "feathers"

it passes compilation but does not actually run properly.

They only install the type definitions and not the source. It also appears that feathers-rest does not export a function for typescript to recognize
rest()' as a valid command for app.use(rest());

Also one more issue, it seems that app.use no longer accepts arguments such as
this.app.use(bodyParser.json());

and must be used as

this.app.use(bodyParser.json() as any);

@Chrisdf I fix this with tgz files in package.json, clone now and try install again.

More details about this: issue

@AbraaoAlves is there a reason you're not putting the definitions on DefinitelyTyped? This way they would be available through the @types namespace from NPM and it would remove the requirement for the core team to keep the definitions up to date as part of a release.

@AbraaoAlves By the way, why were the definitions not committed but instead posted as tarball release? They would be more available for typings this way. I highly appreciate this effort and agree that it would be beneficial to bring the definitions to the community in usable form, DefinitelyTyped will be a good move.

I've re-written the typings based on the work of both @AbraaoAlves and @harangue. I will be submitting these typings to DefinitelyTyped shortly.

Cool. Anything we can/should do for this? Otherwise I'm assuming that once things have been included in DefinitelyTyped we can close this issue?

should be included in this repository and the package.json
(at least that would be best case)

Example: package.json included file

Hi everyone o/
Thanks for patience and feedbacks.

@stevehipwell and @daffl: I believe in typescript definitions file are like a documentation, a live documentation. But documentation that is not aligned with the code is worse than no documentation!

I know @types and DefinitlyTyped initiative, and this important to typescript community on time that javascript guys don't worry about definitions.

Today, if we have the opportunity of maintaining both in a single place, under a single release, communications errors will have a much lower incidence and we'll have officials definitions by release!

Examples of javascript projects maintain your own definitions: Aurelia, Preact, ...

If everyone agrees, here are the PullRequest links:

• feathers
• feathers-authentication-client
• feathers-hooks
• feathers-primus
• feathers-rest
• feathers-socketio
• feathers-authentication
• feathers-client (I will send after these others have resolved)

There much more work todo, like typed-tests, automatation, ... but this is just beginning.

Typescript S2 FeathersJS!

Hi all,

I agree with @AbraaoAlves that the ideal solution is to include the TypeScript definition files with the packages directly, however the worst case scenario is included definition files that end up being out of date. This is why I was suggesting that DefinitlyTyped was used to maintain the definitions as a middle ground solution that is in keeping with the Node mentality of breaking complex things apart into smaller and easier to manage components.

To make sure that the definitions are kept in sync with the project releases there would need to be better transparency from the feathers team. So far whilst writing my own definitions I'm unsure what the current state of the release is; the blog is not kept up to date and there are a number of code names (v3, auk, buzzard??) that mean nothing.

@AbraaoAlves - Your definitions look good, but from what I can see there are areas missing such as the hooks() methods. Would you be interested in adding these in?

Hi @stevehipwell,

Thanks for the feedback. And here is my answers about:

However, the worst case scenario is included definition files that end up being out of date ...
To make sure that the definitions are kept in sync with the project releases there would need to be better transparency from the feathers team

Yes, sync problem is a real problem, but can be fixed with tests.
I make a suggest to make tests in typescript: #508

If agree or not about this solution take your opinion there.

I'm really motivated to make feathersjs a typescript friendly, without disruptive changes, of course.
We have much more work to do, like hooks() methods, but now we can build this together.

If you see a bug or miss a definition, make an issue.

@AbraaoAlves it sounds like there is the desire to keep the definitions up to date and I'm more than happy to help. I assume that you want bug raising on the main repos for missing definitions once your merge requests are completed?

@stevehipwell Yes, it's the point.

What is the issue with the release schedule and what can we do to make that better? The milestones in here are still roughly what we are planning:

• The next release is Auk which is code complete with the generator being finalized and the docs being updated. The breaking changes are in feathers-authentication v1.0.0
• The release after is Buzzard which will include the following breaking core changes (which I do in fact sometimes refer to as v3 - and probably should not 😉):
  
  
  
  • Framework independence (https://github.com/feathersjs/feathers/milestone/9) (and with that a unified structure for the client)
  
  
  • Hooks in core (https://github.com/feathersjs/feathers/issues/408)
  
  
  • Channel based event filtering (https://github.com/feathersjs/feathers/issues/388#issuecomment-239564856)
  
  

What should the process be to update the definitions once those features have landed?

Typescript definitions are like .h (header) in C++. If you have a header that not respond to your module, troubles can happen at runtime, like a documentation not align with the version of the code used.

Therefore, I believe that definitions should be included in each milestone that requires a change in the API, eg: moving method to other repository or add a new parameter to a method, …

I will go change feathers-authentication definition, removing hooks to specific projects to align with v1.
The question now is: Should definitions be included in this current version of FeathersJS?

@AbraaoAlves I think so. I can make a minor release for all your PRs and we can iterate from there. The only thing I'm still wondering about is #508 but I will comment on that.

I have facing two problems with the typings above.

socketio does not want to work.

node_modules/feathers-socketio/index"' resolves to a non-module entity and cannot be imported using this construct.

And rest requires a handler even though your feathers-cli outputs without arguments.

.configure(rest()) // Error here declare function rest(handler:Function): Function;
.configure(socketio())

node -v
v6.6.0

npm -v
3.10.5

tsc -v
2.1.6

It would be interesting also to show how to use "feathers()" as a module since this is the entry point.
I can convert all the other generated services/middleware but there must be a nicer way that encapsulating feathers() in a constructor() {}. (I am new to feathers, I might be doing it wrong too...)

Can we get the definitions out as a patch release? This level of change would perfectly fit a patch release; no breaking changes and no new functionality. Even partial or incorrect typings are better than no typings.

Once we have a release then we have a working starting point that we can use augment to improve the typings.

If this continues to stagnate and will have to go down the DefinitelyTyped route for my definitions. I don't want to have to do this and am happy to help with definitions in the repos.

I had a question for @AbraaoAlves in #508 but have not gotten a reply yet. If we make the releases we need someone available to quickly address any issues that might be coming up (especially since worst case it might break existing apps that are using TypeScript). Can we coordinate on Slack for a good time to make and verify the release (we can start with a minor.pre)?

Released in minor versions for each module via

• https://github.com/feathersjs/feathers/pull/507
• https://github.com/feathersjs/feathers-authentication-client/pull/25
• https://github.com/feathersjs/feathers-hooks/pull/135
• https://github.com/feathersjs/feathers-primus/pull/43
• https://github.com/feathersjs/feathers-rest/pull/101
• https://github.com/feathersjs/feathers-socketio/pull/60
• https://github.com/feathersjs/feathers-authentication/pull/412

First of all, thank you to everybody who participated in this discussion and especially to the ones who contributed. We did release minor versions with the TypeScript definitions for many Feathers repositories but it did cause a number of issues - and unscheduled releases for otherwise fairly stable modules, making users update that even don't use TypeScript at all - with no way for the core team (where nobody uses TypeScript) to reliably fix them.

My main takeaway from the whole Feathers + TypeScript discussion is that it seems to be very hard to create and maintain typings for an existing JavaScript project (to me that didn't speak very well for the interoperability TypeScript claims). Since the core team is not using TypeScript our only choice moving forward when releasing breaking API changes is to remove any outdated TypeScript definitions.

It would be great to have up-to-date TypeScript definitions for the Feathers modules in the DefinitelyTyped repository and we'll do everything we can to help make that happen but with the limited time we have available we can't add the overhead of supporting and maintaining something we don't personally use in our own repositories.

to me that didn't speak very well for the interoperability TypeScript claims

Feathers is perfectly usable without specific typings, it's just plain JS then without the intellisense and types. Especially feathers' plugin system with its heavy use of mixins makes creating typings difficult, because that's a very non-typescripty way of doing things. I'm a regular typescript user (and fan thereof), but went back to ES6 for server-side feathers stuff for now.
Maintaining types seperately seems to be the better suited way here with noone in the core team actually using typescript.

Feathers would be the preferred server side framework for Angular if it played nicely with TypeScript. Just sayin' :-). I'm moving on for now.

@j2L4e I think this will be easier for the next release once most things that are now mixed in by plugins will be part of core. I'm not sure if it will solve the general problem of reliably getting help with this though.

@rjsteinert What is there at the moment should mostly work but yes, as with any open source project you have the chance to either try and help out or move on.

you have the chance to either try and help out or move on.

I'm one of those folks new to Angular, long time JS programmer, realizing how much TS makes life grand and realizing if we don't role with it on the server side the team is going to curse at it and fantasize about to rewriting it every day for the next couple of years. We may after all go with feathers due to lack of options and in that case definitely help out with keeping Typings up to date. Just saying though that when we are passing by and see "our only choice moving forward when releasing breaking API changes is to remove any outdated TypeScript definitions", we look else where. Don't take it as a slight, I do understand the need to support existing projects, y'all aren't lucky enough (I may be doomed) to be in my situation where we are doing a rewrite.

@rjsteinert what does TypeScript offer that makes it so valuable to you? (honest question) After my current set of Feathers work is complete, my curiosity is almost piqued enough by the interest in it to take a look at TypeScript, myself. I know it helps with autocomplete/CodeSense, but the Feathers API is so small I can't imagine it being THAT useful. Please pardon my ignorance. ;)

autocomplete/CodeSense is a nice by-product but I'm usually in Vim so I don't get the goodies. The big shift I see so far is standardizing on how you make it obvious how to use some contributed functions or objects. Looking through libraries in NPM I find a lot of libraries using their own homegrown and creative solution to making obvious and usable what a dynamically typed language doesn't tell you. TS saves a ton of boiler plate of type checking things yourself when you're writing code and makes easier to quickly understand how to use someone else's code. These days I tend to think I'm sick of writing boiler plate JS that's my own style and I really don't want to read someone's README every time I use an external library.

I agree with @rjsteinert, I have worked with JavaScript for 15+ years and I'm a big fan of remembering all the APIs. I even used to code with Notepad without any color. I used to work in a team at Microsoft where the whole site was written with JavaScript only. I can tell you once your site reaches more than 50 programmers, everything becomes a mess. Not only you have to follow more conventions, but your site crashes only at runtime.

If you are writing on this GitHub post and using FeatherJS, you are probably an avid JavaScript developer. If you are one of the FeatherJS developers, you will see no point in using TypeScript for yourself. You don't need any special tooling, or TypeScript help. You are a JavaScript unicorn.
I was extremely against TypeScript (especially that we were forced to use it with version Alpha 1.1), but over the years, I have learned to appreciate it and cannot live without it. The colleagues you will work with will not be as knowledgeable as you are in JavaScript. They will be coming from all different backgrounds, and will be cursing at how JavaScript is a piece of crap.

The TypeScript language has grown so much from the community feedback since then.
You cannot build a massive website with no tooling and a big team. As @rjsteinert says, the team will start using TypeScript for the client side, then after a while, they will be extremely unhappy to use the server side. Effort will be done to change the infrastructure to match their company requirements, then featherjs will be brushed aside.

Have a look at the most popular languages used over the web: PHP, NodeJS, Ruby, C#, Java... Some of them are typed, some of them aren't. I worked with all these languages and I can tell you that after all these years, I don't want to go back to a "discover-error-at-runtime-only" language. They all have their charm, pros and cons. In a large team, I would always suggest to go with something a little stronger and typed.

Most recent example of someone using a PHP SDK I wrote. If you have a method that accepts a "large number" with 100 digits, you actually treat is as a string. The beginner developer will open a bug asking why when calling setValue(123456789123...) does not work, it seems to crash pretty low in NodeJS or in a substr method. Now, the intermediate developer will go check your documentation and find that it should have been a string. Imagine with typing, you force a string to be entered as you type or compile. Then the developer does not need to read the specific documentation neither open a bug.

I researched a bit on which framework to use for my new Angular2 + NodeJS project, and FeatherJS seemed to be just what I needed. However, if another server project came out today and said "I support officially TypeScript out of the box", I'll switch right over.

Thanks for everyone’s input on this issue. There has been some very good discussion but I feel that it is starting to turn towards the merits of typescript and that’s not really what this issue is about. The core team has discussed and we’re not going to support Typescript definitions as they are not essential to working with Feathers and will reduce the rate at which we can evolve the core of Feathers. We already have many things to update when doing a release. We’re trying to reduce dependencies in order to get releases out sooner, whereas adding Typescript definitions would add more work. Since none on the Feathers core team uses Typescript we:

1. don’t have the adequate knowledge to properly maintain definitions
2. cannot spend time working on definitions when a small percentage of our user base “requires” them. We have a lot of other items to work on that impact more people.

For those that wish to create/maintain official definitions we would be happy to link to them in the ecosystem section of the new docs but because don’t use them ourselves and TS definitions are not required when using Feathers and are more of a personal preference we’re not going to maintain them. We’ll be pulling them from the existing repos and @daffl is going to be putting them into https://github.com/feathersjs/feathers-typescript. If @jsgoupil, @rjsteinert, @AbraaoAlves or anyone else interested would like to maintain the repo we'd be happy to grant access and/or transfer the repo. We think this will make it easier to keep the definitions up to date and easier to submit to DefinitelyTyped (admittedly I don't know much about that process).

We’ll leave this issue open for discussion but will lock the thread if it continues down the path of discussing the merits of Typescript as opposed to what needs to be done to implement definitions outside of the core repo. 😄

if you don't want to include this, could you please include the source directories in the versions published to npm and set jsnext:main or module in package.json to the entry

Since TypeScript supports wildcard module definitions now, it'd be an easy workaround to purge all typings from feathers-sub-modules and include this in feathers:

declare module 'feathers';
declare module 'feathers-*';

which will declare feathers and all feathers-whatever modules as type any, which at least "makes it work" with TS out-of-the-box. You don't get enhanced intellisense but it just works without breaking stuff in existing projects and gets the issue off of people's backs.

I also do:

"paths": {
            "feathers-socketio": ["typedefs/feathers-socketio/index.d.ts"]

to "override" incorrect or incomplete typedefs for the meantime, rather than opening lots of small PRs and creating lots of patch versions that don't actually patch anything for non-TS users.

Hi,
I just want to clarify one doubt regarding typescript support.
As per the current type definition of Service , all the service methods are required methods.

But according to documentation, service methods are optional .
See

So, service definition should be something like below isn't it ?

  interface Service<T> extends events.EventEmitter {
    find?(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get?(id: number | string, params?: Params, callback?: any): Promise<T>;
    create?(data: T | T[], params?: Params, callback?: any): Promise<T | T[]>;
    update?(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch?(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove?(id: NullableId, params?: Params, callback?: any): Promise<T>;
    setup?(app?: Application, path?: string): void;
  }

@harish2704 yes that's right

I'm sticking with my "override repo typedefs" workaround for now, and maybe someday (hehe fingers crossed) publish on feathers-typescript or DefinitelyTyped, once I'm done with my project.

That ensures that I'd be submitting some battle-tested definitions on at least one production project.

Thanks Coo!

On Tue, May 9, 2017 at 7:42 AM, Richard Michael Coo <
[email protected]> wrote:

@harish2704 https://github.com/harish2704 yes that's right

I'm sticking with my "override repo typedefs" workaround for now, and
maybe someday (hehe fingers crossed) publish on feathers-typescript or
DefinitelyTyped, once I'm done with my project.

That ensures that I'd be submitting some battle-tested definitions on at
least one production project.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/feathersjs/feathers/issues/381#issuecomment-300138396,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABezn0WGqH30NNp8-X-ckpVuk_BTQbbnks5r4FEQgaJpZM4Jears
.

@myknbani
Might be a bit early to check in - but how did you get on with the typedefs? Do you need a hand at all? :) I'm looking to use feathers in a new project, but the lack of TypeScript support is a bit of a sticking point.

lack of TypeScript support

Not sure what you mean exactly. It does totally work. It's far from perfect, but it works.

@jonlambert I agree with @j2L4e. The existing ones are not perfect, but I just do the trick I mentioned here for anything that does not typecheck.

IMHO, packages like feathers-rest that need only be used in about two lines are not worth typing at all :-)

I can't even remember what I changed, but I think there are no problems using hooks and services.

@j2L4e I was meaning that feathers does not support TypeScript. You're right, it's possible to use them together with the workaround you mentioned above, but it's certainly not 'supported' as we can see by this issue!

TypeScript is integral to our workflow in ensuring our apps are maintainable down the line, so I thought it was worth checking to see if @myknbani's definitions were available. No worries though! 🙂

It works without that workaround as well. There are typings available in the official repos that don't need too much fiddling. No offense, but it seems to me that you didn't even try if it works.

Since none on the Feathers core team uses Typescript we:

1. don’t have the adequate knowledge to properly maintain definitions
2. cannot spend time working on definitions when a small percentage of our user base “requires” them. We have a lot of other items to work on that impact more people.

As a newcomer to the framework I would have thought the presence of this issue, plus the comments above were enough to assume lack of TS support. Sorry if that's the wrong conclusion, I'll be sure to give it a try.

Also, it might "work", but without any form of guarantee to ensure the type definitions stay up to date with the API it seems like it has the potential to cause problems in the future.

You're right.

However, there were quite a few enhancements lately and completion of the typings is planned and in the making.

That's great news 🙂 Really enjoying working with the framework so far and I'm excited to be able to use it with TS 🎉

It works without that workaround as well. There are typings available in the official repos that don't need too much fiddling. No offense, but it seems to me that you didn't even try if it works.

@j2L4e You're right. I think the typedefs are in a much better state now. I deleted all of my "overrides" and the only issue remaining so far are the ! assertions (coz of strictNullChecks) when using app.service(...).

I would suggest separating typings for service definition (where the service methods are all optional) and service instance (where all service methods are not undefined). Currently, I had to painfully add !s everywhere e.g. await app.service('api/foos').create!([{

I had this in my workaround:

interface ServiceDefinition<T> {
    find?(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get?(id: number | string, params?: Params, callback?: any): Promise<T>;
    create?(data: T | T[], params?: Params, callback?: any): Promise<T | T[]>;
    update?(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch?(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove?(id: NullableId, params?: Params, callback?: any): Promise<T>;
    setup?(app?: Application, path?: string): void;
  }

  interface ServiceInstance<T> extends events.EventEmitter {
    find(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get(id: number | string, params?: Params, callback?: any): Promise<T>;
    create(data: T | T[], params?: Params, callback?: any): Promise<T | T[]>;
    update(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove(id: NullableId, params?: Params, callback?: any): Promise<T>;
  }

How bout this:

  interface GetMethod<T>{
    /**
     * Retrieves a list of all resources from the service.
     * Provider parameters will be passed as params.query
     */
    find(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
  }

  interface FindMethod<T>{
    /**
     * Retrieves a single resource with the given id from the service.
     */
    get(id: number | string, params?: Params, callback?: any): Promise<T>;
  }

  interface CreateMethod<T>{
    /**
     * Creates a new resource with data.
     */
    create(data: T[], params?: Params, callback?: any): Promise<T[]>;
    create(data: T, params?: Params, callback?: any): Promise<T>;
  }

  interface UpdateMethod<T>{
    /**
     * Replaces the resource identified by id with data.
     * Update multiples resources with id equal `null`
     */
    update(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
  }

  interface PatchMethod<T>{
    /**
     * Merges the existing data of the resource identified by id with the new data.
     * Implement patch additionally to update if you want to separate between partial and full updates and support the PATCH HTTP method.
     * Patch multiples resources with id equal `null`
     */
    patch(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
  }

  interface RemoveMethod<T>{
    /**
     * Removes the resource with id.
     * Delete multiple resources with id equal `null`
     */
    remove(id: NullableId, params?: Params, callback?: any): Promise<T>;
  }

  interface OptionalMethods <T> {
    find?(params?: Params, callback?: any): Promise<T[] | Pagination<T>>;
    get?(id: number | string, params?: Params, callback?: any): Promise<T>;
    create?(data: T[], params?: Params, callback?: any): Promise<T[]>;
    create?(data: T, params?: Params, callback?: any): Promise<T>;
    update?(id: NullableId, data: T, params?: Params, callback?: any): Promise<T>;
    patch?(id: NullableId, data: any, params?: Params, callback?: any): Promise<T>;
    remove?(id: NullableId, params?: Params, callback?: any): Promise<T>;
  }

  type GetService<T> = GetMethod<T> & ServiceAddons;
  type FindService<T> = FindMethod<T> & ServiceAddons;
  type CreateService<T> = CreateMethod<T> & ServiceAddons;
  type UpdateService<T> = UpdateMethod<T> & ServiceAddons;
  type PatchService<T> = PatchMethod<T> & ServiceAddons;
  type RemoveService<T> = RemoveMethod<T> & ServiceAddons;

  interface ServiceCore<T> extends OptionalMethods<T> {
    setup?(app?: Application<any>, path?: string): void;
  }

  interface ServiceAddons extends events.EventEmitter {
    filter(any?: any): this;
  }

  type Service<T> = OptionalMethods<T> & ServiceAddons;

This allows you to type any non-TS service by constructing a new type, e.g. for feathers-mailer:

type MailerService = CreateService<Mail>;

Or a (quite useless) service that can only create and delete:

type TrashyService<T> = CreateService<T> & RemoveService<T>;

This is all with using selector functions to get services in mind (e.g. app.service(s => s.mailout)) will return that service with its appropriate type. As seen here:

Just checking back in, how are we getting on? @j2L4e post ^ looks really neat! Just wondering what else needs doing to see if I can be of any help.

OK, errors I am seeing so far:

import * as handler from 'feathers-errors/handler';
import * as notFound from 'feathers-errors/not-found'; //[1]

app.use(notFound()); //[2]
app.use(handler()); //[3]

[1]

[ts] Module '"c:/Users/George/Source/Repos/ts4/node_modules/feathers-errors/not-found"' resolves to a non-module entity and cannot be imported using this construct.

[2]

Argument of type 'Function' is not assignable to parameter of type 'PathParams'.
Type 'Function' is not assignable to type '(string | RegExp)[]'.
Property 'push' is missing in type 'Function'.

[3]

Argument of type 'Function' is not assignable to parameter of type 'PathParams'.
Type 'Function' is not assignable to type '(string | RegExp)[]'.
(alias) notFound(): Function

Are there existing workarounds?

https://github.com/feathersjs/feathers-errors/pull/87

For the next version, @j2L4e has been doing some great work on polishing the typings. Here are the steps to try it out and beta test:

npm i -g lerna
git clone -b buzzard-j2L4e  https://github.com/feathersjs-ecosystem/feathers-typescript.git
cd feathers-typescript
lerna bootstrap

lerna will link all the packages and deps for you. Now go to the ./packages/tests subfolder (where no tests can be found yet, so i made it a kind of playground) and try out the TS goodness! Check out index.ts.

To compile and run, run npm start from ./packages/tests

Just started migration from Feathers 2 to 3, index.d.ts files are now missing from the head @feathersjs packages. Any plans to restore them?

As mentioned one comment above, they have been moved to https://github.com/feathersjs-ecosystem/feathers-typescript/tree/buzzard-j2L4e to be submitted to DefinitelyTyped. @j2L4e is too busy right now so it is up to somebody else to pick this up. From what I understood it is mostly getting the Linting passing and submitting them to DefinitelyTyped. I'll happily help whoever is willing to pick this up but have no plans to take it on myself.

Yep, it was a lot more work than i had anticipated and feedback from the community was virtually zero. I will make it happen as soon as i find the time. Not too soon, though.

if anyone would chime in here, it would be really really awesome. It's all about the DT linting now, that aside everythings working fine-ish

a quick copy and paste from slack:

guys, I'm really really busy at the moment, so the typings are anything but top priority. they do work but DefinitelyTyped is quite strict in terms of linting rules. if you could help with making the typings pass the definitelytyped linting process, that would be awesome

check out my DT fork here https://github.com/j2L4e/definitelytyped, you'll find the feathersjs packages in types/feathersjs__packagename

clone, npm install and run the linter on one of the packages, e.g. npm run lint @feathersjs/feathers (edited)

@feathersjs/feathers is already linting properly, so you can use it as a reference. (edited)

TypeScript definitions are waiting for review to be added to DefinitelyTyped at https://github.com/DefinitelyTyped/DefinitelyTyped/pull/22805

Definitions are now accessible via NPM !

Yep, install @types/feathersjs__package for package @feathersjs/package and provide some feedback please!

@erikma thanks for your support!

@j2L4e Thank you for your work! But are you sure you have exported all @featherjs/express functions? I can't find any mention of rest, json, notFound and urlencoded in your typescript definitions file.

you're right, those are missing.

add a typings.d.ts file for now with:

import { ErrorRequestHandler, RequestHandler } from 'express';

declare module '@feathersjs/express' {
    export function errorHandler(options?: any): ErrorRequestHandler;
    export function notFound(): RequestHandler;
    export const rest: {
        (): () => void;
        formatter: RequestHandler;
    };
}

no idea where urlencoded should go.

urlencoded and json have been added to express in the last minor version. Have the express typings not been updated yet?

Is that express or feathersjs/express?

It's just re-exported from Express:

• https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/express/index.d.ts#L31
• https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/express/index.d.ts#L42

So you should be able to do Import { urlencoded, json } from '@feathersjs/express'? Or would you get it from the exported original?

Everything that's exported from require('express') is re-exported by @feathersjs/express: https://github.com/feathersjs/express/blob/master/lib/index.js#L82

Also, do you know how to deal with channels.ts with definitions that are fine?
I'm sorry to throw all the problems at you in such a short time.

Import @types/feathersjs__socket-commons

Import ? I do not understand

Sorry it should actually say 'Import @feathersjs/socket-commons'. You need to install its types.

If I install @types/feathersjs__feathers my app.channel doesn't work. If I then add @types/feathersjs__socket-commons my app.on stops working.

will be fixed via DefinitelyTyped/DefinitelyTyped#23195

please take any further issues over here: https://github.com/feathersjs-ecosystem/feathers-typescript/issues

Issue tracking for TS definitions is a bit confusing. You're directing folks to the feathers-typescript repo but you mentioned _"This repo is now obsolete"_. If you're not going to maintain the definitions in the respective repos and instead utilize DT, I think it'd make most sense to keep the issues in the DT repo as well, since that's presumably where the PRs will originate and be merged.

I think we than decided to give it a try here. I've been getting requests through several channels, and directing people to go over there Was a quick way to centralize that. Personally, i dont really care where it goes as long as it's one place

Is there any reason we can't use feathers.services.dogs instead of feathers.service('dogs')?

Yes. feathers.service('dogs') calls defaultService (which instantiates service on the client) and removes slashes from service names.

TypeScript definitions are now in DefinitelyTyped.

Please direct any issues and questions to https://github.com/feathersjs-ecosystem/feathers-typescript/issues