Typescript Libraries

[SonofNun15]

We are separating our application into distinct repositories to keep the pieces small and reusable.

We want something like DLLs in .NET where a TypeScript repository is compiled down to a distributable that can be imported into another TypeScript project and consumed. The compiled medium in TypeScript is JavaScript, so right now we're compiling down to a .js file and a .d.ts file.

Currently we are using TypeScript internal modules and referencing types in the library globally via namespace. I would rather use external modules with ES6 import statements.

What about adding a feature to the TypeScript compiler for compiling TS libraries into some format that can be imported via a TS ES6 import?

The compile process could check for errors and then bundle all of the included TS files into a single TS file. This solution would require the library TS file to ultimately be compiled to JS with the consuming code, which doesn't allow separate deployment. 😦

Another approach allowing for separate deployment would be dynamic import of .js + .d.ts file combinations in TS.

Thoughts? What is the best way to implement this type of architecture long term? Is there already a strategy for doing this that I missed?

[SonofNun15]

Ultimately, this could change the way the Definitely Typed project works because willing open source projects could include a .d.ts file with the .js file as part of their distributable, potentially allowing the project to be imported via TypeScript...

[Davidhanson90]

Related #4315

[SonofNun15]

Yes, that issue is similar. They encountered some of the same issues that we encountered along the way.

[jpierson]

I have just recently starting looking into solutions for sharing an internal TypeScript library myself and was surprised not to see an existing story on how to accomplish this.

[SonofNun15]

Any response or word from the official TypeScript team on this? Would love to be engaged in any discussion on ideas surrounding TypeScript libraries.

[jbrantly]

Another approach allowing for separate deployment would be dynamic import of .js + .d.ts file combinations in TS.

This was sort of implemented recently. See #4352 and #4504 for example. If you're willing to take the extra step of first compiling your package before publishing to NPM, TypeScript can just natively read and use an associated .d.ts file. Note that this does not mean that these packages are bundled into the TypeScript output. Bundling is a whole separate issue.

I did want to describe how my company is working around this problem as we wanted to be able to do a similar thing (have some "common" TypeScript components that we can easily just import into a project). TypeScript recently added support for custom module resolution logic. This isn't something you can just define from the command line (yet) but for compiler/language service integrations it is available. We use webpack to do all of our bundling, and I recently added support to the webpack TypeScript loader to honor webpack resolution logic (which includes things like aliases). The result is you can alias something like "common" to a shared lib folder and then in any project bundled with webpack you can do import foo from 'common/foo'. You can also configure it so you can do something like import foo from 'foo' depending on how exactly you structure your libs. For example, if the package is published to npm you can just do that without any extra configuration.

Examples:
https://github.com/jbrantly/ts-loader/tree/master/test/aliasResolution
https://github.com/jbrantly/ts-loader/tree/master/test/nodeResolution

[SonofNun15]

So it looks like in TypeScript 1.6 it will be possible to import / require a node package from a folder with a js and d.ts file in it and both will be resolved? 😀

[jbrantly]

So it looks like in TypeScript 1.6 it will be possible to import / require a node package from a folder with a js and d.ts file in it and both will be resolved?

If the package.json of the node package has a typings field (so it's opt-in from the package). I wouldn't say "both will be resolved". The JS file is completely ignored. Just the .d.ts is pulled in for typing information.

[jbrantly]

If the package.json of the node package has a typings field (so it's opt-in from the package).

Actually that's not right, sorry. That's one way to resolve it, but there are some other conventions that TypeScript uses to try to locate the .d.ts file as well. For instance it'll check node_modules/packageName.d.ts and some other locations.

[SonofNun15]

Ultimately this (http://www.jbrantly.com/es6-modules-with-typescript-and-webpack/) is going to be the way to go. Once a library is compiled down to a common JS library it can be consumed by other modules using web pack or browserify. Once Typescript is setup to auto resolve typings via the typings property in package.json it will just work. 😀👍

[SonofNun15]

Now I'm having trouble compiling a single (ambient?) typings file (d.ts) for my library. I'm exporting as a commonjs library that will be deployed via node, but I'm having trouble getting a single d.ts file. Also ran into an issue with ts-loader in webpack where it can't find the npm module even though tsc 1.6 is happy...

[mhegazy]

@SonofNun15, why do you need a single .d.ts file? do you intend to distribute typings with your package or on definitely typed?

[SonofNun15]

Trying to build a compiled TS library. Currently looking to compile as commonjs with a single .d.ts file so that the library can be installed and imported via npm. Consumer should be as simple as:

import myLib from 'myLib';

[SonofNun15]

This looks possible given the ability to now resolve modules in node_modules and use the "typings": property in package.json.