Proposal of a convention about npm modules distribution.

[vilicvane]

There was an discussion about generating ambient declarations for external CommonJS modules: http://typescript.codeplex.com/workitem/2080

But even if typescript generates the definitions as we what we want, we'll still need to add references manually, which is not doing better job than JS libs with NuGet DefinitelyTyped packages.

I propose that when we publish a typescript package via npm, publish the .d.ts file(s) generated with the current style along with it.

So that we can manage to write a tool (or add a feature to something like WebEssentials) to watch related node_modules directory, resolve the definition references and create wrapped definition file(s) under scripts/typings folder.

Thoughts?

[RyanCavanaugh]

I'm not sure exactly what this means? Is this a proposal for community behavior, or a change in TypeScript?

[vilicvane]

@RyanCavanaugh this time it's for community behavior. (Or I need to post it elsewhere?)

[poelstra]

Note that the TypeScript Definition Manager (tsd) is also in the process of 'standardising' this, see https://github.com/DefinitelyTyped/tsd#link-to-package-manager-bundled-definitions

Ideally, TypeScript should produce external typings (when "-m commonjs" is supplied), but until then, one can use e.g. https://github.com/grunt-ts/dts-bundle as a (quick&dirty) tool to convert TypeScript's existing internal typings to external ones.

[vilicvane]

@poelstra thanks for your links, it's good to know there's already main stream tools working on this. :D

[xealot]

We have recently run into the situation where trying to use several Typescript projects that depend on one another can become quite a nightmare. This extends almost solely from the fact that when using external (real) modules the definition files are created per module and there isn't any clear way to concat them, compile them or otherwise export them for use in another project.

We will be investigating your links @poelstra, thank you.

I also wanted to ask if anything has changed regarding this particular situation.

[poelstra]

We started off trying to use the NPM-way of having many small modules, but this was too much hassle. We're still using CommonJS (solely), but are building almost everything as one big NPM module.

We've open-sourced one package for now (https://github.com/SpiritIT/timezonecomplete, shameless plug ;)), for which we also submitted typings to DefinitelyTyped, as the "tsd link" functionality didn't seem usable at the time. We're using dts-bundle for generating these typings, which tends to work great in practice.

So even in our main TypeScript project, we're effectively treating that package as any other 'plain' Javascript package, and 'manually' apply the DT typings. This is suboptimal, but it works.

I think the only strangeness we've had is that VS's IntelliSense occasionally forgets what members the enums in Timezonecomplete have, whereas the commandline compiler accepts the code just fine. Not sure why yet.

If you found a better workflow for using TypeScript modules, I'm very interested in hearing about it!

[xealot]

I want to mention that this most likely has a strong relationship to:
#17

[mhfrantz]

We're interested in a cleaner solution than ts-pkg-installer, which we wrote to address TypeScript modularity in the NPM/TSD ecosystem.

https://github.com/RedSeal-co/ts-pkg-installer

We also use dts-bundle, which complements ts-pkg-installer in that it generates a declaration file that can be installed with ts-pkg-installer.

[mhegazy]

@vladima has proposal in #2338 for managing typings as part of resolving node_modules. the idea is that the package.json would have a "types" as a property, and the typescript compiler will look up that file and use it if it exists. would that work?