These are chat archives for TypeStrong/atom-typescript

15th
May 2015
Basarat Ali Syed
@basarat
May 15 2015 04:46
@mtraynham npm install tsd -g ... no need for the @next anymore.
Nelo Mitranim
@Mitranim
May 15 2015 04:53
it's not marked as release though
on gh
Basarat Ali Syed
@basarat
May 15 2015 07:20
sorry got it
Nelo Mitranim
@Mitranim
May 15 2015 07:21
yeah that one
Nelo Mitranim
@Mitranim
May 15 2015 07:27
nice
kpgarrod
@kpgarrod
May 15 2015 08:16
I'm having trouble with lodash mixins and webpack. I've posted on SO (http://stackoverflow.com/questions/30172767/provide-lodash-with-mixins-globally-via-webpack-provideplugin) and asked in the webpack gitter, but can't find a solution
Now I'm trying to use es6-style 'extends' to add the functions
I've started with
import * as lodash from 'lodash'; class lodashExtended extends lodash{ }
but get an error cannot find name 'lodash'
is this a workable solution?
Basarat Ali Syed
@basarat
May 15 2015 08:27

@kpgarrod

When I log '_' I see that capitalize is in fact a function on that Object.

log _.capitalize you will find it is undefined. If you only log _ you get the opportunity to see a mutated version. => if this is correct then it leads me to believe that you have a ordering issue somewhere in your code :)

kpgarrod
@kpgarrod
May 15 2015 08:42

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
May 15 2015 08:48

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
May 15 2015 09:09

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

export {lodashExtended as _}

@kpgarrod ^
kpgarrod
@kpgarrod
May 15 2015 09:33

@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
May 15 2015 09:41
@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
May 15 2015 09:50
@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
May 15 2015 09:52
@basarat: OK, thanks very much for the help. so you are saying that my module.exports is valid in es6?
Nelo Mitranim
@Mitranim
May 15 2015 09:53
module.exports is runtime CommonJS API, export = ... ambient definition
Oh wait maybe I misunderstand something
you do module.exports in ambient context?
kpgarrod
@kpgarrod
May 15 2015 10:01
@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
May 15 2015 10:06
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
May 15 2015 11:08
Microsoft/TypeScript#3147 sooooish :)
David Driscoll
@david-driscoll
May 15 2015 20:42
@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
May 15 2015 22:18
@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.