TypeScript typings, the TypeScript compiler, and jspm packages

[cmichaelgraham]

TypeScript - Typings for npm packages

finally, the package install for npm can alert the typescript compiler to the location of the package's .d.ts files.

will this work when using jspm to install a package?

[guybedford]

We can certainly look at ways of aligning with these workflows, but I don't believe we do currently.

@frankwallis I'd value your input here. Would it help to do any conversion of this pattern on install in the jspm npm registry endpoint implementation?

[frankwallis]

As far as allowing tsc or your IDE to resolve these typings from within jspm_packages then I believe this will be possible after the implementation of this issue and this has also been raised here

When type-checking within SystemJS, I have tried to implement a solution for loading the typings field (see here), but it involves fetching package.json and then pulling out the value, which is not ideal (and I know it fails sometimes - e.g. when there is no package.json)

If you are suggesting that the typings configuration could be made available in the package configuration at runtime, then that would be a big help for me. Also, sometimes packages will omit this field and put their typings in a file named 'index.d.ts' where the compiler is expected to look for it. When loading from the browser searching the file-system is not possible (AFAIK), so if it was possible to override the typings configuration in the jspm registry then that would also be very useful.

EDIT: Things may also get easier after the implementation of this project: https://github.com/typings/typings

[guybedford]

@frankwallis if there was support for say metadata.typescriptOptions.typings or some API along those lines, it would be possible to add the logic to the npm registry to detect the typings package.json property on install, and then populate that metadata for the loader just for those modules in the package in jspm 0.17. If you think a workflow along those lines might be useful please let me know and I'm happy to create an issue to discuss further.

[myitcv]

@frankwallis - the interesting thing with the typings project is that I'm not entirely convinced (based on this discussion at least) that it will be feasible in all cases to install the 'right' (or at least 'most correct/precise') type definition.

[frankwallis]

@guybedford - it would help somewhat, but I don't think it would be enough. The problem is that the typings field in package.json does not always contain the location of the typings (.d.ts) file. The file can also be located at /index.d.ts or at [module-name].d.ts. The exact resolution algorithm is described here.

The TypeScript compiler can easily search the file-system to look for the files, but when trying to compile from the browser this makes it extremely difficult to resolve them without a pre-created map of module -> typings file.

I am hoping that the typings file will eventually provide (or enable the creation of) a map which I can use to resolve the typings file for each module. In the worst case I may have to deprecate type-checking in the browser - which would be a shame as it is a nice feature for small projects.

I am holding off for the time being to see how things progress.

[guybedford]

@frankwallis thanks for the update. Yes that is not ideal. Surely there is a standard convention though of where to locate it within a single package, just like the index.js ins NodeJS? Is the /index.d.ts case package relative, or project root-relative? Let me know if you're able to discuss this further, it would be good to make sure there is a way forward here.

[frankwallis]

I have raised an issue to look into typings integration: typings/typings#123

[guybedford]

Ok, I'll follow that. Please copy me in as you see appropriate on this.

[MeirionHughes]

Could this be reopened please?

As it stands I'm going to have to using typings to grab the definitions separately; or install the packages again as npm dev-dependencies.

[jakeNiemiec]

@MeirionHughes I currently do something like this to make WebStorm happy. I mirror my jspm packages as npm dev-dependencies to eliminate any problems (like code completion). It is a hassle, but it's the best solution I have found.

[davismj]

The Aurelia team has resurrected this a few times. Keeping the tradition alive.

I'm still a huge proponent of jspm, as I find the advantages outweigh the benefits of any other loader.

I'm building a new project and I'd love to see TypeScript as a first class citizen. It seems like it would just be a matter of inspecting the package.json and pulling in the typings file where specified. TypeScript compiler can take it from there. See here:

https://github.com/aurelia/framework/blob/master/package.json#L17

[aluanhaddad]

@davismj
Thank you for keeping this alive, I very much appreciate it. Aurelia was how I first got started with JSPM and SystemJS.

I fully agree. JSPM and TypeScript are my go to tools for any client side project.

However, this issue is not having JSPM resolve and install the declaration file dependencies. I believe that this would be fairly straightforward.

The problem is that TypeScript is deeply coupled to and reliant on mimicking the behavior of the NodeJS require function. It works with Aurelia's Typings distributions because they are ambient, contributing to a global ambient module namespace.

One of the key benefits of jspm is multi-versioning. Personally, I also value explicit and matching versioning as well. Since TypeScript does not traverse JSPM's config file, it does not resolve non-ambient modules, which are the primary kinds of typings distributed currently on npm, and have the benefit of not colliding in an ambient global namespace, they can be side by side versioned.

Because I wanted exact versions of Aurelia dependencies for my projects, and because I wanted to get the developer experience from the old Aurelia beta that shipped with .d.ts files, I created a tool to accomplish this, but it is framework specific.

It is a complete hack, it is not well designed, but I think it conveys certain difficulties, https://github.com/aluanhaddad/aurelia-types-installer, it is linked purely for illustrative purposes.

That said, we really should resolve this friction.