Repository navigation
Make typings in package.json an array #6585
Description
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"
]
}
Activity
DanielRosenwasser commentedon Jan 24, 2016
Just curious, what is a scenario when your
index.d.tsknows nothing about typings in other folders, but that you want other typings to be automatically exposed?pocesar commentedon Jan 25, 2016
usually exported helper functions and interfaces, that not necessarily is the main code.
take
babel/registerfor example, it's a secondary function that doesn't get re-exported by theindex.jsI 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 commentedon Feb 1, 2016
Declined because we'd rather have a stricter schema.
Easy workaround is to replace your multiple array entries with a single file that has
<referencetags to the desired files.AlexGalays commentedon Feb 6, 2016
I feel that I could use typings being an Array too.
I have a main module
awith its own types; its definition file is the one targeted bytypingsinpackage.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.tsfile 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 commentedon Apr 6, 2016
A note here is that using /// reference tags gets stripped away when doing typings install :(
warren-nixon commentedon May 3, 2016
Ryan Cavanaugh (@RyanCavanaugh)
Typescriptlang.org's Typings for NPM Packages page states:
gmurray81 commentedon Apr 25, 2018
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.