feat(chore): added types definitions

[prudho]

Long time overdue, sorry about that !

Description

This PR adds type definitions for Fomantic's components, enabling them to be more usable on code editors. Typings are now integrated into the actual repository, rather than in the DefinitelyTyped repository, allowing us a better control over type updates and quick fixes. They've been updated to the actual 2.9.2 release, so they should be pretty accurate.

To use them, there's nothing to do since they're included in the package.json. Users should also include jquery types as well in their package.json: npm install --save-dev @types/jquery

There's maybe some comments to add, but it can be released now.

@fomantic/maintainers should I also create a pull request at https://github.com/fomantic/Fomantic-UI-CSS ?

Screenshot

Closes

#396, #1205, #2742

[lubber-de]

Cool and thanks a lot for doing this 👍🏼 I believe you make many people happy 😃

What should we do with https://github.com/fomantic/DefinitelyTyped/tree/fomantic-ui then?
Delete the repo?

Regarding Fomantic-UI-CSS. We are always creating that out of a new FUI release, so usually dont maintain separate PRs there.
I think, for future releases we only need to add the "types" folder and add the "types" key inside package.json just like in this PR, right?

Btw https://github.com/fomantic/Fomantic-UI-LESS also has the single js files for the modules, so should we add the types there as well?

[lubber-de]

LGTM

[prudho]

The DefinitelyTyped repo can be deleted, right.

For the Fomantic-UI-CSS and Fomantic-UI-LESS repo, yes, we just need to add the types folder and add the line in package.json.

[mvorisek]

All JS files should be tested againts the TS interfaces and any missing/extra method/property should fail CI.

[lubber-de]

All JS files should be tested againts the TS interfaces and any missing/extra method/property should fail CI.

That would be worth another PR as it does not seem to be easy. The whole special "behavior" concept (string as first parameter of module call magically matches existing (nested) javascript method tree) would basically work for each existing method inside the modules, but only the "intended" methods are listed in the docs (and only those were covered by prudho here)

A CI, as you suggested, would complain about a lot of unfetched methods as those are not intended to be mentioned.
Of course, it would be consistent to document all of them, even if possibly just used internally by the module, but this would also need a ton of missing documentation for each function. As always, volunteers welcome 😉

I believe this only works out nicely when recoding each module from scratch with a different code structure concept and modern techniques where types and docs can be created/fetched/generated automatically out of the source without the need to manually touch them.

So, I'll merge this PR as it is now and will look for possibly missing new settings in 2.9.3 as this PR "only" covers 2.9.2 which already must have been a hell of work.

[prudho]

@mvorisek yes, this is something i'd like to implement too. A real testing system for each function/property would be great, but like @lubber-de said, this would be a rather large project to test basically everything.

For now, and since we're using an outdated code base, all this work can be done manually, and trust me, there's A LOT of work to do so.

[lubber-de]

The DefinitelyTyped repo can be deleted, right.

@prudho As discussed, I just deleted the DefinitelyTyped fomantic fork