Typings fail to install

[RomkeVdMeulen]

458477c broke our build: typings fail to install. This is because of the same reason described in #279: typings.json refers to dist/aurelia-dialog.d.ts but that file was deleted. It should refer to dist/commonjs/aurelia-dialog.d.ts like it did in RC 1.0.3.

Frankly I'm getting a bit tired of our build breaking because some aurelia module failed to deploy typings correctly. How far along is the plan to support the Microsoft @types packages standard?

[StrahilKazlachev]

Concerning @types packages standard, if you mean publishing to @types, this is definitely not what is recommended for our case - If you control the npm package you are publishing declarations for, then the first approach is favored. - bundling with your npm package. If you find an aurelia package that does not have a types/typings field in the package.json, do open an issue for that module.

[RomkeVdMeulen]

The announcement of the Release Candidate stated that the @types standard would be supported. Has this changed?

It could be that typings are currently shipped with npm, which would work for webpack builds. I wouldn't know: I'm still working with JSPM and I'm not finding any typings in jspm_packages. I'm installing the typings using the typings tool, following the standard set by the typescript-jspm skeleton.

For now I've worked around this by adding version numbers to each aurelia module in my typings.json.

[EisenbergEffect]

@jods4 @niieani What is your opinion on this? Should we be publishing to @types in addition to the typings being distributed with our npm packages?

[StrahilKazlachev]

@RomkeVdMeulen Restored how it was in #280.

[niieani]

@EisenbergEffect to tell the truth I think a better way would be to recommend users install the packages both with NPM and JSPM (then TypeScript will find the typings natively, from the node_modules folder). Otherwise, we'll just confuse and make problems for users that do not use JSPM, and still try to install the @types package. Either way it's a bad situation, I think the this has to be solved by TypeScript team itself (i.e. dynamically referencing outside packages from non-node_modules folders). There's an issue open, but I don't think it's a priority for them, given the relatively small adoption of JSPM, and the Webpack dominance.

[StrahilKazlachev]

I do have setup that uses jspm and I found it way simpler to install both as @niieani said. There is the overhead in traffic and install time. Disk space can also be of a concern for some.

[RomkeVdMeulen]

@niieani I do foresee some confusion among JSPM users with your solution ("I have to install the package twice? So which is used?"), but that may be less important than preventing confusion among other users.

By the way, whether users install the typings through NPM or typings, there is also a problem with versioning. Webpack users don't run into this since typings and code are installed as one. With JSPM / typings however, the method used in the skeletons means that some locked, manually updated version of the code is installed, but the bleeding edge typings are imported with every clean build. Usually that's not a problem, but when breaking changes in the API are introduced the typings may no longer match the code you're shipping with your project. This happened to me when the return type for DialogService.open() changed.

I've solved the problem myself by manually locking typings versions in typings.json to the ones in my config.js, and updating both at the same time. This may be a bit complex for the average user though.

[jods4]

@EisenbergEffect I can answer your question as far as NPM + TS is concerned, but I know nothing about JSPM peculiarities.

The preferred way to ship types is to include them in your NPM package.
From the official docs themselves:

If you control the npm package you are publishing declarations for, then the first approach is favored. That way, your declarations and JavaScript always travel together.

If your package has a main entry point you should have a types property that locate its definition.

That way, when users npm install Aurelia, they will auto-magically have working types in their code.

The @types alternative is essentially meant for consistent discovery of types that don't ship with their official lib.

At least, that's the story when using NPM as your front-end package manager.

[niieani]

@jods4 this is the issue: microsoft/TypeScript#6012

Since JSPM installs all packages into flat directories named: ${name}@${version}, it is not possible to dynamically point TypeScript to the right file. Hence, TS would need to resolve the JSPM config file to find the right directory. A workaround would be perhaps to make a script that creates symlinks of the current version of Aurelia's JSPM packages into node_modules. This way the versions would stay in sync and there would be no need for double installation.

[jods4]

@niieani I see.
I'm out of my knowledge area here as I don't use JSPM.
I used to have Bower for front-end packages, but these days I find that NPM everything (Yarn actually) is the best way to go.

Maybe if installing an @types package would work for JSPM users, we could publish both?

• NPM users -> npm install aurelia-bootstrapper, everything works 😎
• JSPM users -> install aurelia-bootstrapper and @types/aurelia-bootstrapper and co.

The only downside that I see is that it might create confusion amongst other users: "why do you have an @types package?", "do I need it?", "this is not the TS way", etc.

[niieani]

The only downside that I see is that it might create confusion amongst other users: "why do you have an @types package?", "do I need it?", "this is not the TS way", etc.

Yeah. Not sure there's benefit to publishing and maintaining @types, since the users can already simply install the package both with JSPM and NPM.

[StrahilKazlachev]

Closing since no activity for over an year.
If someone still insists of maintaining the typnigs in duality - published under @types and part of the npm packages, please do open an issue in aurelia-framework since this should apply to all Aurelia packages.