-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Package typing inclusion and discovery #5537
Comments
Cross-linking typings/meta #3 for the other side of this discussion. |
I just came here to file a related bug, but I suppose I'll post my anecdote in this discussion instead. AnecdoteI have creating a monolithic library and am trying to publish it on NPM so others could use: https://www.npmjs.com/package/xlib With Typescript 1.6 I thought I'd finally be able to have it be published and usable, but now that I'm attempting, I see the problem of d.ts collisions. My "xlib" uses typings for I was hoping to split my libraries into core/browser/node modules but because of the overlap (using browserify, plus DiscussionUltimately I think the right approach (regardless of feasibility) is to have each project's dependencies be isolated, and non-interacting with other projects. Where projects interact via imports (either in node_modules or via relative paths) there should be duck-typing analysis to dynamically and implicitly determine the type (shape) of the referenced code. |
@jasonswearingen You're absolutely right, which is why I've been working on As for the isolation, definitely. It's already working with |
Thanks for the details @blakeembrey It sounds as though Ambient Dependencies My situation |
Could you elaborate on this? It sounds like agreement here. Ambient dependencies are not installed by default for that exact reason, the node API (or any ambient API) could change, so it's up to the user to have their environment APIs typed. This way, as a package developer, if you're relying on an environment API (e.g. streams1 -> streams2) the TypeScript compiler would error when the wrong streams API exists. It's less of an issue because things are slow moving, but it's even a built-in issue with TypeScript for now - the browser APIs are typed when all you're using is node and that can cause a subtle bug if your relying on type information that is inconsistent with the runtime API.
Sure, but people consuming your package can't get any type information from that. And if they do have a dependency that duplicates from DT, you'll be creating pain for the consumer. Typings does currently work already and solves this. Though, I've only converted a few repos using it: https://github.com/TypeStrong/tsconfig/blob/master/typings.json Edit: In any case, there's still a few weeks of work before everyone can be using this. Especially for beginners to be introduced, since there isn't anywhere as many type definitions as DT right now. However, as you can see, for ambient dependencies I've been consuming them directly from DT anyway. |
@blakeembrey I guess I'm misunderstanding something about Ambient dependencies, I am considering their use versus the ideal case of each module containing (and isolating) it's dependencies. In this situation a I do look forward to trying out |
@jasonswearingen Ok, it's a very specific semantic I'm using right now. Let me try to tidy it up for you 😄 This certainly helps me, because it's helping me understand how I need to frame it and whether naming needs to change (ambient isn't the best name already, it's more like
Absolutely, each module has to isolate dependencies properly. However,
This part is a little confusing to me. The environments have to be compatible, there's no choice as they will both be under the same node version at runtime. 99.99% of the time, you're unlikely to be using something unsupported across node versions, but in that one case I'd like to know my dependency on
Why? If there's something that will break, why wouldn't you want to know before you're invested in it? Here's another example. Does that example make it clear, or worse, on why I think these shouldn't be treated as direct package dependencies? |
Maybe
With my "it's just a |
Typing compatibility is runtime compatibility, unless I'm missing something. Yes, typing information is still decoupled, but what it describes is runtime compatibility.
Easy. That one isn't ambient, it's a normal dependency. Everything will work. Maybe you want to provide more information on what you mean here? Maybe exposing Edit: I just realised you're probably looking at this in terms of DefinitelyTyped. There's a reason I'm releasing |
Yes, I'm talking about a "DefinitelyTyped world", as that's the only one I have experience with!
In my DefinitelyTyped world they are certainly not the same, as the vast majority of |
@jasonswearingen Ok, separate DT for a second and check out something like https://github.com/typings/typed-debug. You can see there's browser typings, and a dependency in
Right, but I'm pretty sure they are meant to indicate compatibility 😉 That's an issue with DT maintenance and why I'll probably leave it at this for now, until I get a blog post done, but you've given me plenty of content and things I need to clarify 😄 Edit: Unless you have more questions, of course! |
From experience this is usually not the case, but rather just missing optional fields or non-critical return values incorrectly set as For example I am right now following a gulp + browserify tutorial and see that the DefinitelyTyped
|
@jasonswearingen What you just explained is the fact that it's not compatible, but it's should to be, which is exactly what I said and you quoted. I'm not sure what went missing in translation there. |
sorry, I am talking about the a program using typings from a |
@jasonswearingen You're still saying the same thing. You wrote a type definition, cool. It's describes the interface of a module. If it's wrong, that's a bug, nothing else. The environment doesn't even come into this. The type definition is describing a module. I'm just not following what you're saying, but I feel like I've responded with same thing a few times so please try re-reading some of the previous responses and checking out the links I pasted. If there's a specific issue or input you have, please ask it. Edit: Can you please open typing/packaging issues in https://github.com/typings/meta. I don't want to continue derailing this issue. The initial issue you posted is solved already with |
Sorry for increasing the frustration level! You are right that this is getting a bit rabbit-holed. Back to directly discussing Package typing inclusion and discovery:As per my original post in this thread stating my anecdote, Anybody here, please feel free to take a look at that |
@jasonswearingen I've been trying to explain it to you, so I'll try being as clear as possible. Using DefinitelyTyped, it's not possible. Using Edit: If you have a typing problem and want to solve it, please open an issue on https://github.com/typings/meta where people can help you. Every package author that uses TypeScript has the same problem as you, including myself (hence Edit 2: You can also open this issue on https://github.com/DefinitelyTyped/tsd where I can also respond to you, if you're after help using DT - the right people will be listening there. |
+1 for anything that will make the pain go away :) I'm linking a set of related Angular 2 issues that shows how annoying things currently are and to help more people chime in: angular/angular#5459 |
And to pile on, we have long struggled with this for Dojo: dojo/dojo-package-template#3 and was hoping some sort of consensus would emerge and would obsolesce dts-generator. |
@jasonswearingen consider using "peerDependencies" instead of "dependency" configuration property insider package.json of you xlib and app. This way you can avoid duplicates and redeclarations. example: https://github.com/aleksey-bykov/generating/blob/master/src/package.json |
Hi, I introduce my useful maintenance-free typings management implementation compatible with .d.ts files of DefinitelyTyped. I don't want to break this model by breaking changes of typescript. |
The example of @falsandtru is interesting because it shows that some JS libraries maintainers are actually against including type definitions in their project. I've had the same experience with Firebase, I proposed the same thing and they did not seem interested. Whatever the future of TS typings holds, it should provide a way to easily make the link between a typings file and some version of the library it describes the types for. Indeed it can still be out of sync, but at least there's some hope that it won't be completely so.. |
@Aleksey-Bykov Thanks for the detail, that indeed is helpful for my plans for xlib, though that's not the problem I was having in this thread (which is, multiple |
TypeScript cannot discover own delivered typings of own and depended packages using package name when I use amd module. 😞 |
This should be resolved with the move to |
This issue tracks our plans and discussion around the current situation with package typings.
Internally, we've been talking about how to better package, locate, and discover typings for packages which do not include their own typings.
The issues which arise around packages and their typings include:
bluebird
, how can I find types for it without skipping a beat?We've spoken with @blakeembrey and his plans for
typings
(a tool to replace/improve upontsd
). We believe that we're both setting out to solve a lot of the same problems, and we'd love to help build much of that functionality into the compiler and language service to create a seamless development experience.We've come up with a number of improvements to pursue on our end, including:
typed-debug
can be installed and provides types for thedebug
module.)We want to make it seamless for users to use typescript with their existing tools and processes, and this includes their dealings with typings. Ideally, we want users to be able to
npm install
their dependencies as they already do and have everything "just work" without further steps or instructions.Tagging @mhegazy @ahejlsberg @vladima @DanielRosenwasser and probably many others who should get tagged for discussion.
I'm sure I've forgetting things from our discussion earlier, so feel free to chime in with the relevant conversion points I've missed.
The text was updated successfully, but these errors were encountered: