These are chat archives for TypeStrong/atom-typescript

3rd
Jun 2015
Jari Pennanen
@Ciantic
Jun 03 2015 04:36
@basarat how would that fix the wrong d.ts? My understanding is that when I type import * as some from 'some-module'; the declaration must contain declare "some-module" { ... } but there is no way to generate this wrapper
If X/package.json is a file,
Parse X/package.json, and look for "typings" field.
if parsed json has field "typings":
let M = X + (json "typings" field)
LOAD_AS_FILE(M).
if parsed json has field "main":
let M = X + (json "main" field without ".js" extension if such exists)
LOAD_AS_FILE(M)
If X/index.ts is a file, load X/index.ts. STOP
If X/index.d.ts is a file, load X/index.d.ts. STOP
Basarat Ali Syed
@basarat
Jun 03 2015 04:39
@Ciantic the plan is we would not need this wrapper for typescript modules. See this comment : https://github.com/Microsoft/TypeScript/issues/2338#issuecomment-95006284 Note there is no declare module 'mylib' yet require('mylib') works
Jari Pennanen
@Ciantic
Jun 03 2015 04:41
oh right, so it Just Works (tm) after the proposal
Basarat Ali Syed
@basarat
Jun 03 2015 04:41
yes
Jari Pennanen
@Ciantic
Jun 03 2015 04:42
I thoguht the proposal should read package.json name attribute
Basarat Ali Syed
@basarat
Jun 03 2015 04:42
Allows faster partial compile which is what I am big on.
Jari Pennanen
@Ciantic
Jun 03 2015 04:42
but it doesn't mention that
I wonder if that proposal has too many ideas baked in, this node_modules/NAME/ logic could be simpler patch
Basarat Ali Syed
@basarat
Jun 03 2015 05:05
Yes. The node_modules portion is actually done and merged in (minus some polish)
Jari Pennanen
@Ciantic
Jun 03 2015 06:48
but it seems like I have to manually add the declare 'my-module' { ... } until TS 1.6 comes out, maybe I'll have to create a script which takes regular external module and wraps it for the time being
@basarat do you know if this proposal goes in to the collision of dependencies? For instance my npm module written in TS uses lodash, and the module which merely uses my module also uses lodash. Now if I try to compile it gives duplicate definition errors because both refer to typings/lodash/lodash.d.ts (just in different paths of course)
Jari Pennanen
@Ciantic
Jun 03 2015 07:01
I found the branch, https://github.com/Microsoft/TypeScript/compare/moduleResolution it doesn't seem to have a definition collision avoidance yet
debuuu
@debuuu
Jun 03 2015 07:02
@basarat, try downloading babylon.2.0.d.ts from here: https://github.com/BabylonJS/Babylon.js
And opening it in a TypeScript project in Atom.
See if you get compile errors.
Basarat Ali Syed
@basarat
Jun 03 2015 07:06
@Ciantic it avoids it because if foo resolves to different files on the file system they are considered distinct already by the type system. This is different from declare module 'foo'
Jari Pennanen
@Ciantic
Jun 03 2015 07:15
hmm, you mean automatic external modules avoids it? Because lodash is coming from definitelyTyped, and it has declare module syntax baked in, I suspect all definitelyTyped definitions do
there has to be a extra measure for typings//.d.ts files
Basarat Ali Syed
@basarat
Jun 03 2015 07:16
@Ciantic for existing definitions yes. Also the part I am talking about is about librarires written in typescript.
Jari Pennanen
@Ciantic
Jun 03 2015 07:17
yes, I think I got that part. But is there some extra code for avoiding collisions in typings/lodash/lodash.d.ts and node_modules/some-dependency/typings/lodash/lodash.d.ts ?
because when I import some-dependency it also refers to it's own lodash
Basarat Ali Syed
@basarat
Jun 03 2015 07:18
@Ciantic yes. There is discussion about that in : Microsoft/TypeScript#2839 but I haven't look at that deeply
@debuuu : BabylonJS/Babylon.js#550
Jari Pennanen
@Ciantic
Jun 03 2015 07:23
I just figured out this, every module should be external module, no module syntax anywhere! (Not going to happen, but still) Then it would just work with your patch always, the older versions and newer versions could live side by side
Basarat Ali Syed
@basarat
Jun 03 2015 07:23
@Ciantic exactly
@Ciantic declare module "foo" is fundamentally global and global is bad for versioning
Jari Pennanen
@Ciantic
Jun 03 2015 07:24
yup
oh, man this is one of those depressing things one would be happier without knowing, there is no way to fix this anymore, too much code with module syntax
Basarat Ali Syed
@basarat
Jun 03 2015 07:29
I feel like saying "commonjs" all things :P (start the :fire: war)
Jari Pennanen
@Ciantic
Jun 03 2015 07:33
yes, maybe I'll go to Microsoft/TypeScript and start the revolution right away :smile:
Jari Pennanen
@Ciantic
Jun 03 2015 07:38
I see you just commented on that one issue, I edited mine. I think it is not easy to find the module resolution issue & branch when first hitting on the issue, that Microsoft/TypeScript#3089 was easier to find
but that suggestion relys on declare module, which is not a right way to go
Basarat Ali Syed
@basarat
Jun 03 2015 07:40
Yes. Thanks for that
kpgarrod
@kpgarrod
Jun 03 2015 16:19
I am getting a message that I don't understand. I am using Promise.all([service1, service2, service3]).then(...). The services all return similar promises, but of different generic types. The message I am getting says: The type argument for type parameter 'R' cannot be inferred from the usage. Consider specifying the type arguments explicitly. Firstly, I don't know what is meant by type parameter 'R' and secondly I don't know how I can specify the type explicitly in this code. Any suggestions please?