typings jspm support for devDependencies

[Steenr99]

We are using this jspm: functionality in 0.17 beta which works great for our private packages that are listed as a jspm dependency.

But we seem to run into errors when we try to pull in typings for a jspm devDependency.

How to reproduce:

Install a dependency on a jspm package that comes with generated .d.ts files
Install the typings for this package using
typings install jspm:packageName

Typing installation is successful.
Move the dependency to a devDependency in the jspm configuration

Run:
typings install -V

The following output is seen:

typings ERR! message Cannot read property 'path' of undefined
typings ERR!
typings ERR! stack TypeError: Cannot read property 'path' of undefined
typings ERR! stack     at resolveJspmDependencyFrom (C:\..\typings\node_modules\typings-core\dist\lib\dependencies.js:396:32)
typings ERR! stack     at C:\..\typings\node_modules\typings-core\dist\lib\dependencies.js:388:20
typings ERR!

Moving the dependency back to the dependency list resolves the build problem.

We are using typings v2.1.0

[unional]

By the way, what is the reason of using jspm devDependency and needing the typings for it?

My experience with jspm devDependency is only related to plugins. So I wonder why would you need the typings. If you need to use them in your code, or during bundling, it typically would be a dependency or install as npm devDependency.

On the other hand, with the advance of TypeScript 2.0, typings as a tool will eventually be deprecated. So the easy alternative is to install the typings using npm install @types\<package> instead.

[Steenr99]

Maybe best to give some background.

We are having a ui application for which we use jspm. Since we share some codes between different applications we have created multiple jspm library which holds the common code.
(we also have some npm libraries that are shared between ui code and nodejs backend code).

All of these libraries are exporting .d.ts files. in the beginning we used createDts to generate our typings file during publishment, but we recently went to let typings do the generation.

For jspm modules we saw that during typings installation, it will also look for typings of all its dependencies.
(e.g. the mapping that is being put in the jspm.config.js file after installing a package).

So we would have angular/angular-router and our own shared packages in the typings file if we list them as dependencies.
This resulted in some typescript error : classes named the same but not equal due to a private modifier issues for some of our own shared packages. (A requires B and C, B requires C)

To avoid this, we started to move some dependencies to the devDependencies so that no typings would be generated (as they are not seen as a required dependency).
the result would be that we needed to import some packages on a higher level, a bit like angular-ui does by not providing the angular package itself.

This went southways the moment we wanted to put our jspm package as a devDependency with above mentionned problem.

That said, we used the workaround you described, by pulling the typings in through npm devdependency instead. The downside of this is that we need to maintain 2 versions in the package json. (but that is the same when using @types for 3rd party libraries)

So our current use case is a workaround around a workaround. Although I can imagine if we would create a library for some of our testing functionality we would run into the same problem.

I don't see how @types will help though. As my understanding is that these are just npm packages of typings instead of installing them through typings. But maybe I need to read more into that?

[unional]

This resulted in some typescript error : classes named the same but not equal due to a private modifier issues for some of our own shared packages. (A requires B and C, B requires C)

Is there a way to resolve this? that seems like the root cause.

@types is the way TS team expose typings in DefinitelyTyped. It is the preferred way to do things. As for your custom typings, you can do similar things if you have a private npm registry.

If you don't, you can still use the typeRoots option in tsconfig.json to point to the right files.
You can also use include: [] to add your custom-typings.

Although I can imagine if we would create a library for some of our testing functionality we would run into the same problem.

In this case more likely you will be installing it as an npm devDeps instead of jspm devDeps, right?

I agree that your situation is a workaround of a workaround, so it is better try solving the root cause or try to use one of the supported mechanisms first.

[Steenr99]

The only way we seemed to get around that error in another way was by making everything public.. which is also not a desired action.

I will need some time to test the other scenario's. I will try to go with @typings and typeRoot/typings to see if we can jump that bandwagon to avoid the different workarounds.
thanks