Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 15 09:28
    pasinduperera synchronize #1514
  • Oct 15 09:20
    pasinduperera synchronize #1514
  • Oct 15 09:11
    pasinduperera opened #1514
  • Oct 02 22:01
    kaiyoma opened #1513
  • Sep 30 20:20
    jfellus edited #1512
  • Sep 30 20:20
    jfellus edited #1512
  • Sep 30 20:19
    jfellus edited #1512
  • Sep 30 20:18
    jfellus edited #1512
  • Sep 30 20:18
    jfellus edited #1512
  • Sep 30 20:17
    jfellus opened #1512
  • Sep 21 09:57
    arcanis opened #1511
  • Sep 20 16:18
    reduxdj edited #1510
  • Sep 20 16:18
    reduxdj opened #1510
  • Sep 20 08:28
    mininek opened #1509
  • 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
kpgarrod
@kpgarrod

I can see what the problem is, but I don't know how to fix it. This is what I get in the log:

user.js:214 Lodash Object {default: function}default: function lodash(value) {VERSION: "3.8.0"add: function add(augend, addend)

I'm doing this:

import * as lodashExtended from 'lodash';
export default lodashExtended

so I see that 'export default' is adding a block around lodash(which does have my mixins mixed in)
kpgarrod
@kpgarrod

in webpack.config I add lodash like this:

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

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