Proposal: Move TypeScript declaration file (.d.ts) to @types/hyperapp

[tetradice]

How about moving TypeScript declaration file (.d.ts) to @types/hyperapp? (in DefinitelyTyped)

As a result, this allows it to be supported by a third party instead of being officially supported in the future. In addition, the following command must be executed to install the declaration file.

% npm install --save-dev @types/hyperapp

If someone wants to update the declaration file, that person sends a Pull Request to DefinitelyTyped repository.

Background

In Hyperapp V1, hyperapp.d.ts was included in the official hyperapp package, and this file was applied just by executing npm install hyperapp. This is convenient for users, but from the viewpoint of the author (@jorgebucaran) and maintainers, it seems to have the following problem.

• Since it is synonymous with official support for TypeScript, if someone enhances or fixes to hyperapp, the type definition file must also be modified. (Otherwise, the implementation and definition will not match) This raises maintenance costs.

Therefore, it may be better to separate the TypeScript type definition file from the official repository and support it on the DefinitelyTyped repository side. (Many other famous libraries such as jquery and react do so)

Disadvantage

The disadvantage of this scheme is that for TypeScript programmers, one more package needs to be installed. As @Swizz has commented before, this is cumbersome.
#518 (comment)

But I think the reduction in official maintenance costs is worth the cost.

[jorgebucaran]

@tetradice Sounds good to me! 👍

[zaceno]

I'm totally for this as I'm not a Typescript user myself (and not particularly interested in becoming one). But I was wondering what to do about all the @hyperapp/* packages? If they are to be typed as well, how would they be handled?

[jorgebucaran]

@zaceno Hmm, in that case, I think that @types/hyperapp would include types for all the modules also, as they become available.

[tetradice]

@zaceno @jorgebucaran I've never tried to contribute to DefinitelyTyped, so I looked into it a little, but maybe the suggestion might not be possible. I've looked into it, and the type declarations for packages of the form @hyperapp/events appear to be customary to distribute in packages named @types/hyperapp__events. For this reason, if we distribute as above, the installation method is as follows.

$ npm install --save-dev @hyperapp/events @types/hyperapp__events

This isn't intuitive, but it's like the type of DefinitelyTyped, so we might have to follow it. 🤔

If we want to set up to just install @types/hyperapp, we may have to use dependencies. In other words, as follows.

(in package.json of @types/hyperapp)

  "devDependencies": {
    "@types/hyperapp__time": "*",
    "@types/hyperapp__events": "*",
    "@types/hyperapp__random": "*"
  }

[jorgebucaran]

@tetradice I see. What about @hyperapp/types and put all type related stuff there? Just a thought.

[tetradice]

@jorgebucaran Unfortunately it is difficult. As far as I know, TypeScript can import in principle only in two ways: xxx.d.ts included in the package and xxx.d.ts included in @types/xxx. is there. So even if we install @hyperapp/types, it is not automatically imported by import {...} from "hyperapp".😢

(I would like a solution that I don't know)

[jorgebucaran]

@tetradice Well, let's keep the type declarations in each repo then.

[diontools]

To load a type definition from @hyperapp/types, I think the user needs to specify typeRoots in tsconfig.json.

e.g.

{
   "compilerOptions": {
       "typeRoots" : ["./node_modules/@types", "./node_modules/@hyperapp/types"]
   }
}

[tetradice]

@diontools As you pointed out, it can be imported if the user specifies typeRoots. But to do that, we will force users to specify build options. I think that is major disadvantage.