restplatinum.blogg.se - Sublime text typescript

#Sublime text typescript code

2012, a year in review The problem with Assert.Different projects require different tools. If you want to load in third party libraries it really doesn’t work too nicely, you end up with any type declarations around which really isn’t helpful. The biggest problem I see is the module system, it’s really shit if you don’t do exactly as Microsoft does, and here in lies the problem. I’d like to try it on a much bigger project, particularly something in Visual Studio to see how well that goes, especially by having things like intellisense working. So with all that considered what’s my thoughts so far? I actually do like it, particularly the way the compiler can catch some stupid mistakes.

You can’t create modules in a function (ok, I kind of get this one).

You can’t create interfaces in a function.

#Sublime text typescript code

The generated code isn’t in a closure scope unless you use a module, which in turn the closure scope is really ridged (particularly from the CommonJS module point of view) which means.

There seems to be no way to plug a definition file into Node.js so all my unit tests are just written in plain JS which really sucks as I changed the API and didn’t realise until every single unit test failed.

It’d be nicer if there was optional AMD support, like how I have it done in db.js, so you can have something that will export as a AMD if AMDs are available, otherwise just be a global object

You can use the AMD support but it forces you to use RequireJS (or CurlJS or any other loader). If you make it a public module it assumes there is a public “exports” object to attach to which is fine in Node.js but sucks in the browser! I had to have a shitty implementation to get it working that assumes in the browser there is the exports object. If you want to go with CommonJS the internal modules they generate create a global variable to store your object in, but that won’t work in Node.js as the variable isn’t exported.

The way modules are generated can be a real pain if you’re trying to target the browser and Node.js.

It’d be nicer if you could just require('typescript') instead of what I have to do in the Makefile Even though TypeScript’s compiler is available as a Node.js package you have to execute the compiler yourself and pass in the input.

The fact you can’t programmatically use the compiler sucks.

If you’re not using Visual Studio it’s kind of a pain, Sublime Text 2 only has syntax highlighting support so you don’t exactly get much benefit, no intellisense or anything.

Fat-arrow => is really sweet, I’d never really got into CoffeeScript enough to have built anything much but I can see why those guys rave about it.

It doesn’t try and stop me from writing any of the funky stuff that I actually want to write ).

I’ve used a class for part of the API which is very handy and easy to use, but most importantly it’s syntactically simple.

Being able to create modules using a keyword is good, save a bunch of boilerplate guff.

Even though I’m not debugging the TypeScript (since it’s run as the compiled JavaScript through Node.js I don’t have source map debugging) the JavaScript looks close enough to my original code that it’s pretty obvious as to where I’m at

The compiler errors can be nice, caught a few spelling errors and API usage errors through them which I wouldn’t have caught until runtime/while the tests were being executed.

The repository should contain the TypeScript source and the output JavaScript, consumers shouldn’t be forced to use TypeScript if they don’t want to.

This is written primarily as a Node.js package but I also want it to work in the browser.I used Sublime Text 2 as my editor, not Visual Studio.

I just want to clarify a few things about how I did this project: Keep in mind this is only a small library so it’s not exactly extensive, but I feel it’s a good start. Well I decided to do this, I wrote a small library called mathy and I wanted to share some of my thoughts from having made something with it. This was the same approach which I took with CoffeeScript, you don’t really know something until you’ve made something with it (and for the record I wasn’t particularly fussed by CoffeeScript). I’ve been doing JavaScript development for a while now, I know many of the ins and outs of JavaScript development and I’ve never seen any problem with the syntax or the lack of type system.īut like a good skeptic I wanted to reserve my opinion until I had a chance to actually use it. When TypeScript was announced I was pretty skeptical of it. That it is over 3 years old, so the content in here may not be accurate. Hey, thanks for the interest in this post, but just letting you know