These are chat archives for TypeStrong/atom-typescript

4th
May 2015
Basarat Ali Syed
@basarat
May 04 2015 00:42
@Zoltu I see you've found the relevant issues : Will be fixed for node_modules : Microsoft/TypeScript#2338 Still an open discussion for typings : Microsoft/TypeScript#2839
^ leaving it here for others :rose:
Micah Zoltu
@MicahZoltu
May 04 2015 00:43
Yeah, took me a day but I managed to formalize in my mind what the real problem was, and it wasn't atom-typescript.
Thanks!
I want to switch over to full TypeScript so badly.
But I know I'll hate myself if I have to manage dependencies by hand, so I keep waiting.
Basarat Ali Syed
@basarat
May 04 2015 01:28
completely agree
Seivan Heidari
@seivan
May 04 2015 01:43
What is the easiest way to execute a .ts file (and not hop over to to the generated js file)?
Basarat Ali Syed
@basarat
May 04 2015 01:43
There is a hidden command Execute in iojs
Seivan Heidari
@seivan
May 04 2015 01:43
Ah, thought that was it.
Basarat Ali Syed
@basarat
May 04 2015 01:44
@seivan I've been using it for testing. And not for public use so not documented :rose:
Seivan Heidari
@seivan
May 04 2015 01:44
Where would that output be?
Basarat Ali Syed
@basarat
May 04 2015 01:44
@seivan I'll make it public as a part of TypeStrong/atom-typescript#238
@seivan the output will be on the atom console
Seivan Heidari
@seivan
May 04 2015 01:45
Btw, this plugin alone is the only reason I am ditching CoffeeScript for this.
Holy crap it's so good. It's like being in Xcode again.
Basarat Ali Syed
@basarat
May 04 2015 01:46
thanks :)
Mike Graham
@cmichaelgraham
May 04 2015 01:46
i spent the whole weekend porting aurelia library changes. always do my work in atom-typescript. it is really fantastic - thank you so much @basarat
Seivan Heidari
@seivan
May 04 2015 01:47
This happens as well with the current version TypeStrong/atom-typescript#310
Basarat Ali Syed
@basarat
May 04 2015 01:48
@seivan same reason : No steps, just re-focused the editor after having it unfocused and the editor crashed.?
Seivan Heidari
@seivan
May 04 2015 01:53
@basarat Yes! Btw was this the console? https://atom.io/packages/log-console
Basarat Ali Syed
@basarat
May 04 2015 01:55
@seivan nope. Its built in :
blob
Seivan Heidari
@seivan
May 04 2015 02:08
Woo, got 4.1.1
Basarat Ali Syed
@basarat
May 04 2015 02:09
@seivan yes. I'm hoping it helps with #310
Seivan Heidari
@seivan
May 04 2015 02:09
Hey, so how do I alter the keymap? I want to change the autocomplete stuff to toggle with 'esc' and scrolling down with 'tab'
Basarat Ali Syed
@basarat
May 04 2015 02:11
@seivan I don't recommend down with tab (you will need up as well I think). But you can do whatever you want : https://github.com/atom-community/autocomplete-plus#usage
Doesn't sound too crazy though so worth a try! :rose:
Seivan Heidari
@seivan
May 04 2015 02:12
Thanks! Nah I don't need up :)
Hmm.. I thought typescript used its own autocomplete and not autocomplete-plus
Basarat Ali Syed
@basarat
May 04 2015 02:19

I thought typescript used its own autocomplete and not autocomplete-plus

Nope. We use autocomplete-plus. Just happen to install it silently so you don't have to :rose: we also install linter :)

Seivan Heidari
@seivan
May 04 2015 02:28
Got those already :D
Seivan Heidari
@seivan
May 04 2015 02:36
Wow...
I would have never switched to Typescript without this plugin.
Damn it's so good.
Basarat Ali Syed
@basarat
May 04 2015 04:09
oh-stop-it-you.png
When just a simple :rose: is not enough
Jari Pennanen
@Ciantic
May 04 2015 04:40
pretty frustrating MS is not developing VS Code in the open
Basarat Ali Syed
@basarat
May 04 2015 04:42
Indeed. But I am sure they will be forced to realize the folly of that plan. Github did the same with atom in the beginning.
It would just be better if they got it from the beginning.
Jari Pennanen
@Ciantic
May 04 2015 04:43
excatly
When I started using atom-typescript, I thought they had implemented the single file transpilation ( Microsoft/TypeScript#2499 ) but no! It's not in VS Code either. I was ranting about it in codeplex long time ago
Basarat Ali Syed
@basarat
May 04 2015 04:45
That's another reason why I don't like --out
Jari Pennanen
@Ciantic
May 04 2015 04:46
yeah, but isn't this basic thing, people just want to transpile single files, how can they get this part wrong :smile: had they developed this in open you could have merged your effort on single editor
I'm just looking at atom-typescript/emitter.ts
Basarat Ali Syed
@basarat
May 04 2015 04:47
:rose:
Jari Pennanen
@Ciantic
May 04 2015 04:49
what I advocated, is basically having single file transpilation always, and optional type/semantic checking in background (or in command line) this way Edit + F5 is fast, but you still get the type check goodies if one is willing to wait
Basarat Ali Syed
@basarat
May 04 2015 04:50

is basically having single file transpilation always

That's actually a good idea. I should move to transpile. But the thing is that with --module compile on save has been sub second anyways.

Jari Pennanen
@Ciantic
May 04 2015 04:53
hmm, can TSC do single module compilation?
Basarat Ali Syed
@basarat
May 04 2015 04:53
Yup. It has a transpile function now
Jari Pennanen
@Ciantic
May 04 2015 04:54
it's not in the command line interface
it's probably keeping VS code from implementing it, because it uses the command line interface if I'm not mistaken
Micah Zoltu
@MicahZoltu
May 04 2015 04:56
What makes single file transpilation hard?
Jari Pennanen
@Ciantic
May 04 2015 04:56
oh, that Issue is using two terms "single module transpilation" and in the body "--singleFileTranspile"
Micah Zoltu
@MicahZoltu
May 04 2015 04:56
Is it because that file probably has dependencies, but those dependencies have already been transpiled and you don't want to waste CPU/time transpiling them again when only one file has changed?
Jari Pennanen
@Ciantic
May 04 2015 04:57
exactly, I think it should've been default
@Zoltu there is this though: You have A -> B dependencie, you change A and now B is not transpiled and goes broken
but really, it doesn't happen too often
Micah Zoltu
@MicahZoltu
May 04 2015 04:58
So you believe that by default tsc foo.ts should only generate foo.js, not also generate foo-dependency.js (from foo-dependency.ts)?
Jari Pennanen
@Ciantic
May 04 2015 04:58
one can just compile whole program when deploying to production
it just make development time edit + F5 slow when it compiles all files each time
Micah Zoltu
@MicahZoltu
May 04 2015 04:58
(assuming that foo.ts imports foo-dependency.ts)
In theory, TypeScript could keep a cache file somewhere that tracks the dependency tree. Then it can know when A depends on B and B changes that A needs to be recompiled as well.
If the cache file isn't present, then build everything.
Jari Pennanen
@Ciantic
May 04 2015 04:59
I think it should be default in IDE, because it makes edit+F5 workflow faster, but maybe in "tsc somefile.ts" it should compile all changed dependencies
Micah Zoltu
@MicahZoltu
May 04 2015 05:00
Would you be satisfied if this only worked for tsconfig.json projects?
Basarat Ali Syed
@basarat
May 04 2015 05:00
Before I rant : please note that single file transpilation is not a problem for atom-typescript if a.) you use external modules. b.) you compile with preserveConstEnums

In theory, TypeScript could keep a cache file somewhere that tracks the dependency tree. Then it can know when A depends on B and B changes that A needs to be recompiled as well.

No need if you use external modules

Micah Zoltu
@MicahZoltu
May 04 2015 05:01
I believe I use only external modules.
Though, the whole internal vs external thing always confused me. I use the ES6 import syntax and compile to ES6.
Jari Pennanen
@Ciantic
May 04 2015 05:02
@Zoltu, I think the single file transpilation as a default in IDE / Editor is a good way to introduce typescript, no configuration etc. That's why Atom makes it so easy to try TS.
without tsconfig.json requirement
Micah Zoltu
@MicahZoltu
May 04 2015 05:02
I think atom creates a tsconfig.json for you.
At least, something did when I added my first .ts file to my atom project.
Basarat Ali Syed
@basarat
May 04 2015 05:03

At least, something did when I added my first .ts file to my atom project.

Its atom-ts

Micah Zoltu
@MicahZoltu
May 04 2015 05:03
Why aren't class method definitions syntax colored? in atom-ts?
Jari Pennanen
@Ciantic
May 04 2015 05:03
could be, but I just remember when I tried atom-typescript, it just emitted the file I was editing, which is what I wanted
Basarat Ali Syed
@basarat
May 04 2015 05:04

Why aren't class method definitions syntax colored? in atom-ts?

TypeStrong/atom-typescript#71

Micah Zoltu
@MicahZoltu
May 04 2015 05:04
Ah, okay. Too bad. :'(
Basarat Ali Syed
@basarat
May 04 2015 05:04

I just remember when I tried atom-typescript, it just emitted the file I was editing, which is what I wanted

This is still true. If you want to emit all you use build.

Micah Zoltu
@MicahZoltu
May 04 2015 05:05
Is there a way to tell TypeScript being compiled to ES6 to not complain about external modules not being found?
Everything works, but I get errors in atom-typescript (and from my gulp build process).
Jari Pennanen
@Ciantic
May 04 2015 05:05
other thing btw, about TypeScript is that it re-creates identical files, it's annoying, it triggers a lot of watching apps
if I have a webpack/browserify watching the js files, and compile TS project, it re-creates all files, even though they are identical
another reason to use single module transpilation in IDE, always
Micah Zoltu
@MicahZoltu
May 04 2015 05:06
@Ciantic I avoid that by having everything end up in an out directory, which isn't watched.
For regular files, they are just copied on change. For files that need transpilation, they are transpiled on change and moved to output folder.
Jari Pennanen
@Ciantic
May 04 2015 05:07
you are not processing them during development?
Micah Zoltu
@MicahZoltu
May 04 2015 05:08
So my source folder has .js (written by hand) and .ts side by side. When a .ts file changes, it is transpiled and the output is put into my output folder. When a .js file changes, it is copied straight over to the output folder.
So the JS files generated from TS files never end up in a watched folder.
Same goes for css and html, the things I am touching while I code are not the things that are served. Gulp watch makes sure that every time I touch something it is copied.
For files that don't need transpilation, the copy is almost instant, so it doesn't really hurt development speed.
Jari Pennanen
@Ciantic
May 04 2015 05:10
hmm, I think you are not using webpack?
Micah Zoltu
@MicahZoltu
May 04 2015 05:10
I am not doing any packing in development.
Jari Pennanen
@Ciantic
May 04 2015 05:10
because webpack requires one to watch JS files, they may contain calls like require("style.less")
which are watched by webpack
Micah Zoltu
@MicahZoltu
May 04 2015 05:11
I'm not familiar with webpack. For development I am just serving up a folder on disk (my output folder).
For dependency management and module loading I am using JSPM, though it looks like webpack does a bit more than that?
Jari Pennanen
@Ciantic
May 04 2015 05:13
webpack can additionally transpile, take dependencies from these "require('style.less')" type of calls
Micah Zoltu
@MicahZoltu
May 04 2015 05:13
JSPM does both of those as well.
Jari Pennanen
@Ciantic
May 04 2015 05:13
so I can make it copy e.g. "component" resources just by including them with require
if JSPM looks for "require" calls it should watch JS files right?
Micah Zoltu
@MicahZoltu
May 04 2015 05:14
import 'bootstrap/css/bootstrap.css!';
import sweetAlert from 'bootstrap-sweetalert';
import 'font-awesome';
JSPM uses SystemJS as its runtime module loader.
You bootstrap your application with SystemJS and it does dependency resolution.
So I would do something like jspm install font-awesome, which would download font-awesome onto my machine. Then in any .js file I can do import 'font-awesome'; to get the font-awesome css injected into my page.
(I am not 100% clear on how the CSS injection bit works, the JS resolution is more clear)
Jari Pennanen
@Ciantic
May 04 2015 05:17
I'm just reading about it, I have not figured out how it differs from webpack
Micah Zoltu
@MicahZoltu
May 04 2015 05:17
As I said, I haven't used WebPack so I can't really compare. I went with JSPM because it is really ES6 friendly and because the framework I am using leverages it heavily.
Jari Pennanen
@Ciantic
May 04 2015 05:18
it could be the ES6 part, I've yet to see webpack begin used with new import statement
Micah Zoltu
@MicahZoltu
May 04 2015 05:20
Yeah, I think JSPM's primary selling point is that it is "the future" rather than the past.
Everything is built around the ES6 module system and polyfilling that, rather than making things work withe legacy module systems (AMD/CommonJS).
If you aren't doing ES6 development though, it may not be a great choice.
Jari Pennanen
@Ciantic
May 04 2015 05:23
oh it's fun to keep changing the package / dependency libary :smile:
Micah Zoltu
@MicahZoltu
May 04 2015 05:23
Hah!
Jari Pennanen
@Ciantic
May 04 2015 05:23
maybe I should try this jspm
Micah Zoltu
@MicahZoltu
May 04 2015 05:24
If you are happy with WebPack I would stick with it.
Unless you weren't joking about having fun changing dependency systems.
Jari Pennanen
@Ciantic
May 04 2015 05:24
I think I will try it on small projects
I'm still stuck with browserify on bigger ones
Jari Pennanen
@Ciantic
May 04 2015 05:35
I just read that external module is the "normal" module without "module {}" syntax. If TS single module transpilation always works with those, it's even more amazing single module transpilation is not implemented already
Basarat Ali Syed
@basarat
May 04 2015 07:39
typeAssertPropertyAccess.gif
Basarat Ali Syed
@basarat
May 04 2015 08:07
latest feature pushed ^ quick fix to do type asserts on property access
Nelo Mitranim
@Mitranim
May 04 2015 08:07
Oh nice didn't even think you could do that in TS
:rose:
kpgarrod
@kpgarrod
May 04 2015 08:49
@basarat: I'm going to bite the bullet and implement webpack :).
I see in https://github.com/TypeStrong/atom-typescript-examples/tree/master/multipleCompileTargetsthat you are adding a typescript-loader and also compiling-on-save. Is it necessary to do both?
Jari Pennanen
@Ciantic
May 04 2015 09:00
I don't think it's necessary, the webpack can watch
Basarat Ali Syed
@basarat
May 04 2015 09:01

Is it necessary to do both?

Like @Ciantic said. You would want to disable compile on save :rose:

Jari Pennanen
@Ciantic
May 04 2015 09:02
compile on save (or transpile on save) is useful for small projects, e.g. quick adhoc editing the ts files or just introduction to TS. It works without configuring
kpgarrod
@kpgarrod
May 04 2015 09:05
thanks
Jari Pennanen
@Ciantic
May 04 2015 09:05
and of course, if you work on pure node modules, the webpack is not required and compile on save works just fine
sigh I hope the Atom team gets their act together and improve symbols view, and navigation. I've ranted about those two features before, but now it's even more important as VS code is released, they make VS code easier to navigate
kpgarrod
@kpgarrod
May 04 2015 09:16
mmm. with compileOnSave:true and no typescript-loader, my little test was working fine. Now with (awesome-)typescript-loader and compileOnSave:false, I get: ERROR in ./app/index.ts /Users/admin/Documents/workspace/coachcommune/app/index.ts:0:25 Cannot find external module 'angular'.
import angular = require("angular");
kpgarrod
@kpgarrod
May 04 2015 09:25
Is there a reason why it's better for webpack to compile the ts than atom-typescript?
Jari Pennanen
@Ciantic
May 04 2015 09:32
because you use it for many other things too
you are running the watch for other reasons, e.g. resource copying etc
Jari Pennanen
@Ciantic
May 04 2015 09:39
@kpgarrod I think you must just add /// <reference path="typings/angular/angular.d.ts" />
not sure, but it's usually the references
kpgarrod
@kpgarrod
May 04 2015 09:45
@ciantic: great! thanks
Jari Pennanen
@Ciantic
May 04 2015 09:55
are you trying angular 2? It's written TS in mind
Jari Pennanen
@Ciantic
May 04 2015 10:02
I've got small irritant with angular 2, after you try react, you see how easy it's to get compile time type safe templates. Major bonus if you are in to type safety, they should implement something like that in Angular
Nelo Mitranim
@Mitranim
May 04 2015 10:33
TypeScript noob question. Can I use the TypeScript compiler to automatically generate .d.ts from my source?
Mike Graham
@cmichaelgraham
May 04 2015 10:34
compiler option: declaration <== true
Nelo Mitranim
@Mitranim
May 04 2015 10:35
oh
:)
Nelo Mitranim
@Mitranim
May 04 2015 10:36
nice
Mike Graham
@cmichaelgraham
May 04 2015 10:39

check out this awesome sauce from @EisenbergEffect:

from this repo:

autoinject tested and working !! :) kudos to @EisenbergEffect

flickr.ts

import {autoinject} from 'aurelia-framework';
import {HttpClient} from 'aurelia-http-client';

@autoinject
export class Flickr{
  heading = 'Flickr';
  images = [];
  url = 'http://api.flickr.com/services/feeds/photos_public.gne?tags=rainier&tagmode=any&format=json';
  http:HttpClient;
  constructor(http:HttpClient){
    this.http = http;
  }

  activate(){
    return this.http.jsonp(this.url).then(response => {
      this.images = response.content.items;
    });
  }

  canDeactivate(){
    return confirm('Are you sure you want to leave?');
  }
}

generated code:

        Flickr = __decorate([
            aurelia_framework_1.autoinject, 
            __metadata('design:paramtypes', [aurelia_http_client_1.HttpClient])
        ], Flickr);
        return Flickr;
Nelo Mitranim
@Mitranim
May 04 2015 10:41
Huh. Does it use special TS compiler features? Or just custom decorators
Probably dumb question but hard to tell offhand
Mike Graham
@cmichaelgraham
May 04 2015 10:42

there are no dumb questions imho :)

experimental compiler option: --emitDecoratorMetadata

Jari Pennanen
@Ciantic
May 04 2015 10:43
just discovered, "Aurelia is a next generation JavaScript client framework" I'm sold right there :clap:
Nelo Mitranim
@Mitranim
May 04 2015 10:43
Does this square with ES7 reflectoin?
Mike Graham
@cmichaelgraham
May 04 2015 10:43
i believe katz, eisenberg, ms ts team, and others are working together on this
Nelo Mitranim
@Mitranim
May 04 2015 10:44
Ooh nice
Really looking forward to this sort of thing being standardised
Not a fan of DI but at least we'll have a codified way of doing it
Jari Pennanen
@Ciantic
May 04 2015 10:45
in ASP.NET 5 (vNext) DI is kind of nice
Nelo Mitranim
@Mitranim
May 04 2015 10:45
In JavaScript it's been nothing but pain for me, still don't get the point
Maybe it's an application scale thing
Jari Pennanen
@Ciantic
May 04 2015 10:45
I've yet to need DI in JS
or if I have, I haven't called it such in JS
Mike Graham
@cmichaelgraham
May 04 2015 10:46
going offline for a bit :) ciao :)
Nelo Mitranim
@Mitranim
May 04 2015 11:30
TS noob question. When defining an "external" module, can you export an internal interface without redefining it?
Jari Pennanen
@Ciantic
May 04 2015 11:56
you mean re-export?
I find weird stuff with that, only thing I can come up is "export interface A extends Original {}" but I think it's not ideal
Jari Pennanen
@Ciantic
May 04 2015 12:01
also by searching, I found this gem:
import a = require('./a');
export import B = a.A; // Important use of import
but I don't think it is internal in that eaxmple
Nelo Mitranim
@Mitranim
May 04 2015 12:02
TypeScript has so much legacy in its module definition system, it drives me mad
Intuitive things don't work
Jari Pennanen
@Ciantic
May 04 2015 12:03
yeah, I tried this "export B = A"
Mike Graham
@cmichaelgraham
May 04 2015 17:10
@basarat you out there somewhere? i have a toughy i'd like to run by you. i'm trying to get decorators to work for aurelia dependency injection.
Mike Graham
@cmichaelgraham
May 04 2015 20:58
problem solved !! thank you @mhegazy !!! :) Microsoft/TypeScript#3024
Basarat Ali Syed
@basarat
May 04 2015 23:24
:rose: