Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Aug 15 17:06
    chaffeqa opened #1508
  • Aug 08 16:07
    lierdakil closed #1507
  • Aug 08 16:07
    lierdakil labeled #1507
  • Aug 08 11:43
    rahamin1 opened #1507
  • Aug 07 12:07
    lierdakil labeled #1505
  • Aug 07 12:07
    lierdakil closed #1505
  • Aug 06 21:51
    TheEmrio closed #1506
  • Aug 05 14:22
    TheEmrio opened #1506
  • Jul 15 15:40
    Xapphire13 closed #1496
  • Jul 10 13:23
    akonwi opened #1505
  • Jul 10 04:44
    nelson6e65 edited #1504
  • Jul 10 04:40
    nelson6e65 opened #1504
  • Jul 08 06:40
    sshquack closed #846
  • Jun 17 16:02
    akonwi opened #1503
  • Jun 02 18:18
    tanfonto opened #1502
  • May 28 17:11
    jazzdragon opened #1501
  • Apr 29 01:12
    dyping closed #1500
  • Apr 28 06:56
    dyping edited #1500
  • Apr 28 06:54
    dyping edited #1500
  • Apr 26 11:38
    dyping opened #1500
Basarat Ali Syed
@basarat
@kpgarrod export = is not supported in es6 .... < not entirely true (you can do it if your export is not callable and only has members you access) but doesn't work well
kpgarrod
@kpgarrod
@basarat: OK, thanks very much for the help. so you are saying that my module.exports is valid in es6?
Nelo Mitranim
@Mitranim
module.exports is runtime CommonJS API, export = ... ambient definition
Oh wait maybe I misunderstand something
you do module.exports in ambient context?
kpgarrod
@kpgarrod
@mitranim, not as I understand it, but I'm a newbie to commonJS and Typescript and ES6, so I am open to correction!
Nelo Mitranim
@Mitranim
Well if you're not getting errors then module.exports and export = is fine
But this combination of export and definition is a pain to consume with external ES6 code
If you add {__esModule: true} to your CommonJS export, then import _ from 'lodash' will work fine, but right now you'll probably get TypeScript errors when trying to import it like that (TS will want you to do import * as _ from 'lodash' but this won't work at runtime)
Oh wait I'm talking about the SystemJS environment
Disregard that if you're not using it
Basarat Ali Syed
@basarat
Microsoft/TypeScript#3147 sooooish :)
David Driscoll
@david-driscoll
@basarat are you going look at taking the completions.json out of https://github.com/atom/autocomplete-atom-api to create a d.ts? I'm currently looking at it myself.
Basarat Ali Syed
@basarat
@david-driscoll nope, but great idea. The API definitions I have are enough already ;). I'm more interested in getting a better ui framework (not space pen) in place 🌹
@david-driscoll while I have you, how are you guys shipping changes to omni server. I'm using onDidChange and its line handling is deplorable : https://github.com/TypeStrong/atom-typescript/blob/master/lib/main/atomts.ts#L182
^ or at least that's my experience.
Micah Zoltu
@MicahZoltu

@basarat What do you mean by

except for the typings stuff as I don't see the rational for that considering there is no way to have tsc send .js to one location and .d.ts to another location.

Re Microsoft/TypeScript#3147
Basarat Ali Syed
@basarat
blob
From Microsoft/TypeScript#2338 ^ I don't read typings on package.json
Basarat Ali Syed
@basarat
FWIW 4.4.0 should be a lot less flaky :rose:
Mike Graham
@cmichaelgraham
updating to 4.4.0 - thanks for all the hard work :)
Steve Ognibene
@nycdotnet
Is there any reason why suggestions must appear while I'm in the process of typing a comment?
Basarat Ali Syed
@basarat
@nycdotnet nope. Its the built in fuzzy provider => not atom-typescript. That said I do find these suggestions mildly useful (if not entertaining) :D
Steve Ognibene
@nycdotnet
ok then
well you may be pleased or horrified with this commit to grunt-ts (pay no attention to that it broke the build), but we can assert parameters on the task and target now: TypeStrong/grunt-ts@9d9ff76
I'm really please with how atom's working at the moment - thanks for your hard work as always
Patrick Toy
@patrickjtoy

So, I noticed an apparent change in how atom-typescript is choosing where to locate compiled JS files, and I'm not quite sure how to get it back to how it was originally working. I've got a file structure for my project that looks like Root > Scripts > Src and Root > Scripts > Built where TS files live in Src and JS files in Built. My tsconfig.json is under Root (and above the Scripts level) and has the property "outDir": "./Scripts/Built" which used to take a TS file from Scripts > Src > SomeSubdirectory > SomeFile.ts and place it in Scripts > Built > SomeSubdirectory > SomeFile.js. Now, however I'm getting Scripts > Src > SomeSubdirectory > SomeFile.ts compiled to Scripts > Built > Scripts > Src > SomeSubdirectory > SomeFile.js. Can I no longer have my tsconfig.json at the Root of the project? Does it need to be inside Root > Scripts > Src and point to ../Built?

TL;DR: why are my TS files being emitted to the outDir with the directory structure up to where tsconfig.json lives?

Patrick Toy
@patrickjtoy
Nevermind the above, I took a look at my tsconfig.json, made a tweak to the filesGlob param, and everything appears to be outputting correctly again.
kpgarrod
@kpgarrod
I'm having problems with the type definitions for angularFire (https://github.com/borisyankov/DefinitelyTyped/blob/master/angularfire/angularfire.d.ts). I know it's a bit off-topic but I would really appreciate some help. I have a service which returns an AngularFireObject. AngularFireObject extends AngularFireSimpleObject. AngularFireSimpleObject contains my data. I understand that to be handled by [key: string]: any; in AngularFireSimpleObject. The problem is, when I try to access one of my own property x on that object, I get a ts error: Property x does not exist on type AngularFireObject.
Basarat Ali Syed
@basarat
[key:string] will only work if you access like foo['x'] not foo.x
@kpgarrod ^
kpgarrod
@kpgarrod
@basarat: aha! Thanks for your support as usual.
kpgarrod
@kpgarrod
@basarat: I don't know if you had a look at the angularFire tsd, but I think the implementation is poor. It doesn't seem to give any type protection to user data. I would like AngularFireObject/AngularArrayObject to be generic, so that I can pass the type of my user object and get type-checking on the returned user data. I just can't get my head around how to do that :(
I tried extending the defs with my own interfaces but I couldn't get that to work
Nelo Mitranim
@Mitranim
@kpgarrod I started with AngularFire and quickly rolled back to the vanilla Firebase library with Fireproof for promises
suggest trying the same
AngularFire is just not productive to use, as it turns out
You'll have to include scope.$applyAsync() into callbacks but that's a small price
kpgarrod
@kpgarrod
@mitranim thanks. I gave up on angulaFire for a long time, but have had a good experience with 1.0, until now!
Nelo Mitranim
@Mitranim

It's convenient to have base viewmodel methods to shorter data sync declaration. For example:

constructor() {
  super()

  this.sync({
    langVal: this.lang,
    wordsVal: this.words
  })
}

Would be equivalent to:

constructor() {
  super()

  this.lang.on('value', snap => {
    this.langVal = snap.val()
  })
  this.words.on('value', snap => {
    this.wordsVal = snap.val()
  })
}
And when using Fireproof, you can $q.all the first complete sync
It's also easy to make directives to three-way-sync data on inputs
kpgarrod
@kpgarrod
@mitranim thank. I have a big bunch of AngularFire models (70-ish) and I'm quite happy with the way they work apart from type-checking. If I could fix the angularFire typedefs to be generic I would be smiling!
Nelo Mitranim
@Mitranim
Oh nice to hear it works for you
kpgarrod
@kpgarrod
thanks for the tip about fireproof. I also use native Firebase in some places and usually wrap it in my own $q resolve/reject. Fireproof could save me a few lines of code!
Nelo Mitranim
@Mitranim
If you're using ES6 modules and run your code outside angular factories, you might have to do angular.injector(['ng']).get('$q') initially to bless Fireproof, then re-bless it with an instance of $q from your application's injector after the application bootstrap
De Lille Felix
@flieks

@Mitranim I puted <reference paths in a tsconfig.json in the /src folder but it's not picked up in a ts file
the code

/// <reference path="../typings/aurelia/aurelia-framework.d.ts" />
/// <reference path="../typings/breeze/breeze.d.ts" />
/// <reference path="../typings/aurelia/aurelia-http-client.d.ts" />
/// <reference path="../typings/aurelia/aurelia-router.d.ts" />
/// <reference path="../typings/es6-promise/es6-promise.d.ts" />

{

    "version": "1.5.0",
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "noImplicitAny": false
    }

}

So then in a ts file (without any references) with a Promise type it fails now (it succeeded before)

Nelo Mitranim
@Mitranim
Huh no that's not what I meant :D