Built in support for typescript types in meteor packages

[perbergland]

The meteor build and packaging system, isobuild, has no support for including typescript type files (.d.ts) as part of a package.
This has lead to types instead being published via the huge definitelytyped repo, which works OK but see below.

It would lead to a nicer experience if typescript types were supported properly as being part of meteor packages and exposed to typescript compilers (there are at least two - the built in file-by-file transpiler and the refapp:meteor-typescript that compiles all typescript files at once via a project) as part of the build process.

I envision this feature to ONLY cover the ability to mark files as "type files" and put them somewhere for the typescript compiler to pick them up. Some other feature should be built to allow for packages to create their own .d.ts files for publishing.

My thinking on the first part is to introduce a new method package.js so that it becomes possible to write

Package.onUse((api) => {
...
api.types("index.d.ts")

This would then just include these special files in the published package.

On the second part, it becomes necessary to agree on a new convention on where to put type files for used packages with the project itself because the typescript compiler needs to find these in the same way that it finds types for npm packages in the node_modules directory.

I suggest a new root directory "meteor_packages" or "meteor_package_types" where the build tool could then use conventions similar to npm/yarn to populate this directory. You can then modify typescript settings (tsconfig.json) to include this directory as a type root.

meteor_packages

• some-package
  • 1.2.1
    • index.d.ts
• some-other-package
  • 0.3
    • othername.d.ts
    • file.d.ts

I would argue against putting these files within node_modules because that directory is owned by npm/yarn and should not be changed by other tools.

[filipenevola]

Hi @perbergland, thanks for adding this issue here.

How is this problem solved in other tools?

I believe adding this info here could help us deciding the best way to solve this in Meteor.

[perbergland]

I have no idea but I also don’t know of any javascript build tools that use their own package format instead of npm :)

[filipenevola]

I mean what files and folders does npm/yarn use?

We should try to follow as close as possible.

[perbergland]

npm/yarn doesn’t have a version number in the paths so maybe that’s overkill.

As for what the exact directory structure needs to be for typescript to understand it I think it warrants further investigation…

We want

import * from "meteor/packagename"

to work like it does today, obviously

[CaptainN]

I'd rather have the scratch directory in .meteor/local. Seems cleaner.

[perbergland]

I'd rather have the scratch directory in .meteor/local. Seems cleaner.

Letting the compiler traverse into dot-directories feels like it would go against the spirit of unix so I would argue against that idea.

Putting types inside some magic directory in the "packages" directory (which already can contain local packages) is maybe better.