Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Global Typings - can / should I add them to npm package? #24

Closed
ccrowhurstram opened this issue Jun 13, 2016 · 7 comments
Closed

Global Typings - can / should I add them to npm package? #24

ccrowhurstram opened this issue Jun 13, 2016 · 7 comments

Comments

@ccrowhurstram
Copy link

ccrowhurstram commented Jun 13, 2016

I've published an npm package: angular-cc-appinsights.

The package is targeting front-end angular 1 developers and will therefore be loaded as a script tag from the the locally installed node_modules directory.

The package is written in typescript and compiled to JavaScript with declaration files.

Reading the examples of how to publish my typings, I seem to fall into both example 2 and 5.

I have gone with option 5: include in the npm package the compiled JS and declaration files.

I suspect packaging global typings might be wrong...

At first blush, this seems to be the right thing to do. Certainly when I go and install my package into an angular application written in typescript the typescript language service picks up my typings from the npm package.

However, I have a nagging feeling I'm not doing things correctly or at least not in keeping with the spirit of the typings project.

My doubts are two fold:

1. I had to manually amend the d.ts file produced to include:

declare module "angular-cc-appinsights" {
    import appinsights = cc.appinsights;
    export = appinsights;
}

2. My definitions expose dependencies from the angular (1) typings installed from definitely typed.

This I believe is a problem as I should somehow be describing which specific version of angular typings I'm depending on

Can you guys point me to the correct approach?

Thanks
Christian

@blakeembrey
Copy link
Member

Hey! Sorry for the delayed response, it's sometimes hard to get back to you when it's a huge question without a clear answer.

As the module you want to type is not an external module, you can not use the typings field in package.json. However, you can still publish the definition and provide documentation to your users. For example, tell them that a definition exists and they can add it to their tsconfig.json files (or using /// <reference />).

@ccrowhurstram
Copy link
Author

No problem for delay, I'm just grateful you were able to given time pressures.

So, basically I cheated by making my global type declaration "look like" an external module to the typescript compiler (my first point)!

The trouble is that my cheat works in practice. The consumer can write:

\\ import the AppInsights class
import { AppInsights } from "angular-cc-appinsights";

The compiler is satisfied.

At runtime it also works. This is because the consumer will only ever use the type interfaces to declare the type of variables. The consumer will be an angular application and so angular will be injecting the actual instances of these types.

Question: So my cheat works, but what negative consequences will I be inadvertently introducing?

@blakeembrey
Copy link
Member

There's only really two issues:

  1. Confusion. Make sure consumers understand what's going on, modules being elided isn't a well known feature. This is also a very non-standard usage, not a great thing to promote.
  2. Values. Make sure it's never used in a value position, otherwise the import will be emitted and code will break - a new user might give up if they hit this.

There are some features in TypeScript 2.0 that may help you - such as being able to specify some types in tsconfig.json and UMD support.

@ccrowhurstram
Copy link
Author

Got it.

The new features you're referring to, that looks like it obsoletes typings tool and maybe the typings registry.

I also see that you've weighed in on some issues that discuss these proposals, for example microsoft/TypeScript#7125 and microsoft/TypeScript#9184

Questions:

  1. Do you think in practice that these new features, as currently specified, will mean we stop using the typings tool and registry?
  2. Or do you think there are some corner cases that need ironing out with these new features, and until such times typings will still have a value proposition, at least for the short term?

@blakeembrey
Copy link
Member

You can probably find answers from me in other places, but basically:

  1. I hope so.
  2. Absolutely, there's still a lot of cases that need sorting out until 2.0 is released. Other projects like JSPM, Bower and Meteor will still require it. But I'll be doing what I can to make 1 happen.

@ccrowhurstram
Copy link
Author

OK, thanks for the heads up.

BTW, useless platitudes of course, but thanks for all that you're doing to help sort out these painful areas of typescript.

@blakeembrey
Copy link
Member

Not useless to me 😄 Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants