Make typings in package.json an array

[pocesar]

Sometimes the main file (like index.d.ts) won't, (and IMHO, should not) reference all the other .ts files from the project. Imagine I have 15+ folders each has a .ts and a .d.ts declaration for it, index.d.ts knows nothing about those files, because index.ts doesn't use them directly.
What about if typings could be an array, and you would be able to specify the order of the typings like:

{
"typings": [
   "./index.d.ts",
   "./somefolder/file1.d.ts",
   "./somefolder/file2.d.ts",
   "./somefolder/file3.d.ts",
   "./anotherfolder/file1.d.ts"
]
}

[DanielRosenwasser]

Just curious, what is a scenario when your index.d.ts knows nothing about typings in other folders, but that you want other typings to be automatically exposed?

[pocesar]

usually exported helper functions and interfaces, that not necessarily is the main code.
take babel/register for example, it's a secondary function that doesn't get re-exported by the index.js

I keep all my interfaces separated in a file so I can reuse them without having to compile code along with it. like interfaces that are used in frontend files, that can also represent server entities, but I don't want browserify (for example) to bundle my entire server file just to extract some information.
using import { that, those } from 'server-file' sometimes bring the whole server file to the frontend, usually when using enums (not const enums, although I'm not sure if it's a bug, my mongoose models get included in the browserify because of a string enum)

[RyanCavanaugh]

Declined because we'd rather have a stricter schema.

Easy workaround is to replace your multiple array entries with a single file that has <reference tags to the desired files.

[AlexGalays]

I feel that I could use typings being an Array too.

I have a main module a with its own types; its definition file is the one targeted by typings in package.json.
However, I also have an optional module a/addon/b, that needs its own typings. This module is imported separately (and optionally) from the main module so as to not bloat the size of the main module with things users only occasionally need.

I can't find how to expose both typings without asking my lib users to explicitly link the addon typings in their fileGlob. Declaring the optional module inside the main module's ambiant definition is forbidden, and so is linking it with <reference>.

Any idea on how to do that without a typings Array and with it being fully transparent to the lib users?

EDIT:
I randomly tried adding a a/addon/b.d.ts file and it picked it up. Oddly enough, doing the same with the main module didn't work, it seems I have to explicitly link it from package.json->typings.

[pksorensen]

A note here is that using /// reference tags gets stripped away when doing typings install :(

[warren-nixon]

@RyanCavanaugh

Easy workaround is to replace your multiple array entries with a single file that has <reference tags to the desired files.

Typescriptlang.org's Typings for NPM Packages page states:

Your definition files should

• be .d.ts files
• be written as external modules
• not contain triple-slash references

[gmurray81]

Here's an important scenario. It's still very easy to confuse tree shakers with Typescript (calling mixin combiners, static properties, static methods, etc). Anything that resembles a side effect will cause a module to not get dropped from the payload. In a perfect world, the tooling would be able to figure out that these are not external side effects and relate only to the classes within the module.

But we don't live there yet, so having a barrel file rexporting everything as an entry point file is currently a liability if you rely on tree shakers being able to limit the scope of what gets bundled I to the app payload.

Now, we don't need an entry point file to distribute code in an npm package. Users can import individual modules from the tree of files in a package. But there's all sorts of tooling that can't behave intelligently unless the package.json can hint it at what to look at. But this is all currently geared toward a single entry point.