Have you considered publishing ui-router with the TypeScript definitions included?

[johnnyreilly]

Hi all,

I'm very excited to read about the port to TypeScript.

I was wondering if you'd considered publishing the ui-router type definitions with ui-router itself given you're building with TS? TypeScript supports this scenario pretty well since 1.6. Doing this would mean that TypeScript users wouldn't have to separately acquire a type definition from Definitely Typed or the Typing Registry. (I'm involved with both BTW)

In case you haven't heard about publishing with typings in the box, I've previously blogged about this: http://blog.johnnyreilly.com/2015/09/authoring-npm-modules-with-typescript.html (There's probably far better content out there as well 😄 )

Any chance this might happen?

PS Great to see the work on supporting components too - looking forward to taking that functionality for a spin.

[johnnyreilly]

Actually - it looks like they're there! Do you have an example of using them in a TypeScript project? I'm wondering what these should become: (angular.ui.IStateProvider and angular.ui.IUrlRouterProvider being the old definitions for 0.2 from definitely typed)

        $stateProvider: angular.ui.IStateProvider,
        $urlRouterProvider: angular.ui.IUrlRouterProvider,

[johnnyreilly]

Hmmm... After some experimentation I found I can do this:

import { StateProvider } from "./node_modules/angular-ui-router/commonjs/state/state";

Oddly this doesn't work:

import { StateProvider } from "angular-ui-router/commonjs/state/state";

Not sure why...

[christopherthielen]

you should be able to import most symbols directly from "angular-ui-router"... here's a minimal setup that worked for me:

[johnnyreilly]

Aha! It looks like the secret sauce is the "moduleResolution": "node". Awesome!

However, I think I may have unearthed a problem. I'm a noImplicitAny kinda guy and it looks like that doesn't play too well with ui-router; the following errors are showing:

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\ng1\viewDirective.d.ts
(10,9): error TS7010: 'resolve', which lacks return-type annotation, implicitly has an 'any' return type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\common\hof.d.ts
(113,27): error TS7006: Parameter 'ctor' implicitly has an 'any' type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\common\hof.d.ts
(113,37): error TS7006: Parameter 'x' implicitly has an 'any' type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\common\hof.d.ts
(115,27): error TS7006: Parameter 'comp' implicitly has an 'any' type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\common\hof.d.ts
(115,37): error TS7006: Parameter 'x' implicitly has an 'any' type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\state\stateBuilder.d.ts
(3,54): error TS7006: Parameter 'parent' implicitly has an 'any' type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\transition\transitionServ
ice.d.ts
(75,35): error TS7006: Parameter 'error' implicitly has an 'any' type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\common\common.d.ts
(13,37): error TS7006: Parameter 'X' implicitly has an 'any' type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\common\common.d.ts
(163,63): error TS7006: Parameter 'T' implicitly has an 'any' type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\common\common.d.ts
(163,66): error TS7006: Parameter 'key' implicitly has an 'any' type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\common\common.d.ts
(165,71): error TS7006: Parameter 'T' implicitly has an 'any' type.

ERROR in C:\source\poorclaresarundel\PoorClaresAngular\node_modules\angular-ui-router\commonjs\common\common.d.ts
(165,74): error TS7006: Parameter 'key' implicitly has an 'any' type.

I should say that usage of noImplicitAny is pretty commonplace. A few extra type annotations and those issues should vanish. Is it worth me raising this as a separate issue?

[christopherthielen]

I think we have an issue reported already... yep #2693

[johnnyreilly]

Great - thanks!

[bfricka]

I would suggest publishing the definitions, even if this can be used with modules, for two reasons:

1. Many people using regular JavaScript can use the definitions to provide type hints. This can be done using WebStorm (and similar JetBrains IDEs) as well as using Tern to convert the definition files to its format.
2. Many people are stuck using the "old" module foo {} TypeScript module definition format and can't reasonably upgrade a large project to ES6 modules immediately.

I'm in the second camp, so this would require me to generate the definitions as part of a build step, or type them manually.

Is there any reason why this couldn't be added as a build step?

[Maximaximum]

Indeed, publishing the type definitions as a separate @types package would be great!

Currently, I'm using bower for managing frontend packages, and ui-router among others. However, typescript support in VS Code is quite limited - the type definitions get automatically loaded only from the node_modules directory, but not from the bower_components.

[johnnyreilly]

I think what you need is typeRoots - https://www.typescriptlang.org/docs/handbook/tsconfig-json.html

[Maximaximum]

@johnnyreilly could you please give me a hint on how typeRoots can solve my problem? Please also note that throughout my application I'm only using typescript namespaces, not modules (no import/export/triple-slash-reference directives), and I have one output js file that gulp produces by concatenating all the compiled js and ts files.

[johnnyreilly]

Sorry I think you might be out of luck - I think using external modules might be a requirement in the context of shipping TypeScript in packages

[johnnyreilly]

For more background: https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/

[christopherthielen]

I'm going to confirm that we won't be separately publishing to DefinitelyTyped, nor will we be publishing non-modules typings. The maintenance of both of those are things I'm not comfortable owning.