Storybook: Type definitions - TypeScript

[Hotell]

Hi folks!

Will you accept PR with type definitions for addons ?

I've them ready in my angular CLI starter, so if you give me thumbs up, I'll submit PR so everyone can benefit from it :)

cheers

[igor-dv]

Oh, it will be very nice, though I'm not sure where is the right place to put them since some parts are already placed in DefinitelyTyped. IMO we need to store them here, so it will be much easier to change/add stuff.
CC, @alterx , @joscha

[Hotell]

there are very few of those in definitely typed repo:

anyways lemme know 🖖

[joscha]

We had them here and noone maintained them, so we moved them to definitely typed - it's been working much better ever since I think, so I'd probably stay with that for now. I am happy to move them back if we decide that there is a clear benefit, but we get linting there, everyone can find them easily, the releases are regular, etc. Maybe decoupling this discussion from actually getting any type definions will be more fruitful - @Hotell I can help you prepping a definitelytyped pull request?

[Hypnosphi]

Definitely typed repo is the place to host TS definitions for libraries

[Hotell]

Definitely typed repo is the place to host TS definitions for libraries

I disagree :) having types side by side with implementation is the best possible option ( if you have maintainers that can handle that ofc ). Releases are synced with API + semantic versioning. just sayin' ;)

[Hypnosphi]

@ndelangen had some objections against forcing our contributors to deal with types

[DanielRosenwasser]

I've been around long enough that I can say all this with some confidence. As a TypeScript and DefinitelyTyped maintainer, I understand the desire to have types closer to the definitions, but Definitely Typed has a much better publishing story for updates to type definitions. We can also immediately test any @types packages that depend on a given package.

When your .d.ts files are in the same repo as the source, repo owners have to totally understand TypeScript or have a high tolerance for churn on files they don't understand. They also have to be willing to publish patch versions to npm.

That said, I think DT maintainers would love any feedback and help they can get from original authors on packages. @hotell does some awesome stuff in TypeScript, so I'm sure he and the community would appreciate it.

[Hotell]

what @DanielRosenwasser said 💯👌

anyways I'll submit types to definitely typed. no hard feelings :)

❤️storybook and thx for all the work you put into it folks !

[igor-dv]

Reopening this issue due to requests/discussion with people
CC @ndelangen @kroeder

[ndelangen]

@DanielRosenwasser So you suggestion is to keep them inside the separate repo?

Can you explain to us what the best approach is to keep it updated and in sync?

---

or have a high tolerance for churn on files they don't understand

This was the reason I advocated for pushing to type definition files to @types previously.

I feel as if this community has changed in this regard over the past year, and more and more people are expecting typescript.

Highly value your opinion on the matter; in fact, all maintainers their opinions for that matter.
My personal preference isn't all that important, what's agreed upon by the overall majority and doesn't exclude people is.

[abbottdev]

Take, for example another highly used library - momentjs. They bundle their typings into their dist, without definitely typed. I think definitely typed was always meant to be a stopgap for owners that didn't have time, or just plain weren't interested in Typescript.

Now, that's somewhat opinionated. But with the tooling available today it's probably easier to automate typings for TypeScript than it was years back.

[kroeder]

Type automation can be troublesome as well as doing everything yourself.

E.g.

function getSomething() {
  return "myString, yay - easy to handle";
}

// Generates 
getSomething(): string;

But:

function getPackageJsonContent() {
  return fs.readFileSync('package.json');
}

// Generates
getPackageJsonContent(): any;

While any does work, I would not recommend this. Either do it right or don't do it.
With a bit of research I found this https://github.com/Microsoft/dts-gen

It's for one-time generation of all possible types. I have not tested this but assume it really generates types for everything. This is just a blue print! After using it, 1-2 people should check all of them and change any to the actual type.

I would drop everything except the public api.
Why? If we would type everything, Storybook could just move it's whole code base to TypeScript (I know you all want this 😄 )

Typing the public api seems maintainable as well. Bigger refactorings need a bit of knowledge but IMO if you ever used a typed language before you can count 1+1 together and copy-paste from already existing types

What is my personal motivation having types inside the mono-repo?
Storybook supports typescript projects but can't guarantee that types in @types do work with a new published version of storybook.

Brings me to my second point: Currently, lots of 3.x.x types do work with 4.x.x but you don't actually know if they really do - They don't have the same version.

Third point: TypeScript projects using strict do need types for everything! I do have such a project. If you have no types while using import { ... } from @storybook/... then you are forced to write your own locally in a typings.d.ts - Thats bothersome. Why would someone do this? We increased our code quality with strict: true. We found type bugs we had not seen before - Code was more testable etc.

Maybe there are more but I don't want to write a book about Why I love typings 😄

This is again my personal opinion as a TypeScript Angular developer with strict: true

[igor-dv]

I agree.

[lemcii]

// ./typings/react-advanced-form.d.ts

import { Story } from "@storybook/react";

declare module "@storybook/react" {
    export interface Story {
        addParameters(parameters: any): this;
    }
}

...for any lazy React devleopers looking.

[ndelangen]

Tracked in #5030

Will close this in favour of that issue