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
kpgarrod
@kpgarrod
so I see that 'export default' is adding a block around lodash(which does have my mixins mixed in)

in webpack.config I add lodash like this:

lodashPlugin = new webpack.ProvidePlugin({
_: 'common/lodash_mixins'
}),

kpgarrod
@kpgarrod
If I could just get rid of the default block, my problem would be solved
Basarat Ali Syed
@basarat

If I could just get rid of the default block, my problem would be solved

export {lodashExtended as _}

@kpgarrod ^
kpgarrod
@kpgarrod

@basarat: then what I get is an object with _ as function lodash(value) as a method. If I just use:

lodashPlugin = new webpack.ProvidePlugin({
_: 'lodash'
})

then _ is function lodash(value)

in the first case, the function has my mixins added
kpgarrod
@kpgarrod
@basarat: well, I have a solution!
in lodash_mixins I use module.exports = lodashExtended;
where lodashExtended is lodash + mixins
so now the only (minor) issue for now, is how to code that in es6 syntax?
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