Announcing 0.9 early previews

Announcing 0.9 early previews

Rate This
  • Comments 27

Today we’re making an early preview available which showcases some of the new features coming in 0.9.0 preview release.  It’s intended for users who wish to try out these features, begin porting existing applications, and who don’t mind a few rough edges in the compiler and language service along the way.  Users who wish to stay on stable builds may wish to skip this early preview and wait for the 0.9.0 preview release (or grab the current 0.8.3.1 preview release).

Background

The 0.9 series marks a major milestone on the way to our 1.0 release.  This series brings major changes to the TypeScript language, compiler, and language services.  With it, the language now supports generics, the top-most requested feature, along with improvements to the type system.  In addition, the compiler and language service have been rewritten, largely from scratch, to work better with large projects in an interactive environment, which allows working with projects of more than 100k lines with little to no slowdown.

The Early Previews

Many users have requested the ability to try 0.9 during its development.  Up to this point, the best way to try it was to use the command-line based compiler by checking out the ‘develop’ branch, but because of the incompatibilities between the 0.8 and 0.9 language services there was no way to use the techniques mentioned in a previous blog post, leaving users of Visual Studio without a way to also try out 0.9. 

The early previews are snapshots of the Visual Studio plugin that are compatible with the latest language service APIs in the 0.9 work.  The intent is to unblock users who wish to stay up-to-date and continue to explore 0.9 features as they’re created.

How to Use It

By default, the first early preview contains a snapshot of the ‘develop’ branch called ‘release-0.9.0-alpha’ and can be installed just like our previous preview releases.  This snapshot features generics and overloading-on-constants.  We’re continuing to add new features and polish the implementation, so to keep up-to-date, you will need to update your compiler and language service from the ‘develop’ branch.  We’ve written about how to do this in a blog post.

Known Caveats

Because the early previews are snapshots of our current work-in-progress, not all functionality from 0.8.3 has been ported to the new architecture.  Features known to not be complete in the first early preview, or are known missing:

  • Refactor/rename 
  • Debugging support
  • Find all reference
  • Compile-on-save

Breaking Changes

Due to the deep changes in the language and compiler, there are some incompatibilities between the 0.9 series and the last preview release, 0.8.3.  Some of these changes come from tightening the compiler to align more closely with the specification.  Others are breaking changes made to improve the overall TypeScript experience in the long run.  For the list of breaking changes between the 0.8.x series and the 0.9 series, see the wiki page.

Path to TypeScript 0.9

We’re continuing to push toward the 0.9 release, and we hope this early preview provides an opportunity to get some additional feedback on new and changed features.  For those who aren’t afraid to dive in to a work-in-progress, we hope this gives you the chance to help us make TypeScript a better, richer, project.

Leave a Comment
  • Please add 6 and 8 and type the answer here:
  • Post
  • Generics!!!! Yay!!!!!!

  • Great news !!! Fortunatelly debugging works, so this is acceptable to me to switch to this alpha.

    Some questions:

    - Missing features (complete debugginig, rename, etc) will be added with new typescriptServices.js or we must wait for new VS plugin ?

    - Do you plan to support indexers in classes ?

    Could be nice to write:

    class YAList<T1>

    {

    Add (Item : T1) {...}

    [Index:number] : T1

    }

    For now, we must create mirrored interface (IYAList), move indexer to this interface, and perform some wild casting to properly instantiate class and assign to variable typed as interface. This means mounts of unnecessary work.

  • Congrats on this progress. I've been flying the TypeScript flag at user groups here in the UK; it'll be nice to have something shiny and new to talk about.

  • Sweet lovely generics! Can't wait to try it when I get home :)

  • Hello,

    Until now, it seems that merging modules and amd has no interest because in amd mode, the import statement refers to a file (e.g. greeter.ts/js). So all the content of the file is considered as "a module".

    While using the simple module strategy, we may define the same module throuthrough several files, e.g. module Views widespread on view.ts, views.ts, ... It is quite convenient...

    What I would like to have is the following : be able to do as with the simple module strategy, and also be able to import the module itself and not the file in AMD mode like this : import views = module ("Views")...

    The typescript compiler would then make itself the references we need..

    Best regards

    Xavier

  • @Xavier - we're currently working on a feature that will let you do something like that.  It will allow you, at the bottom of an external module, to do something like this:

    //fileA.ts

    module A { ... }

    module A { ... }   // combine the two or more A's

    export = A

    //fileB.ts

    import "fileA.ts" as myModuleA  //reach into the file and get the exported "internal" module

    Syntax might change, but the idea is that you'll be able to "export = " not just internal modules but also other features like classes and functions.  This will let you span multiple files, and it has the added benefit that the names you use to refer to these values can be the simple names you give them (like 'myModuleA') above, without having to reach through the imported module for the contents you care about.

  • @jonathan

    thanks a lot for your quick answer, and more especially for this next to come feature we really need IMO.

    Otherwise, I appreciate a lot this language, and the flexibility it offers... I just miss an eclipse plugin ;)

    best regards

    Xavier

  • Rehi Jonathan,

    is the new feature will enable this schema?

    //fileA.ts

    module A { ... }

    export = A

    //fileB.ts

    module A { ... }   // combine the two or more A's

    export = A

    //fileC.ts

    import "fileA.ts" as myModuleA  =module(A)

    import "fileB.ts" as myModuleA  = module(A)

  • I'm not sure if that style would be supported, because once we codegen the first import, we would have to thread the result into the second one.

    You can span files, but you would need to span before you did the export, like this:

    //fileA.ts

    module A { ... }

    //fileB.ts

    ///<reference path="fileA.ts"/>

    module A { ... }   // combine the two or more A's

    export = A

    //fileC.ts

    import "fileB.ts" as myModuleA

  • @Tristan

    Missing features will be added, where appropriate, to both the VS and language service, just as they were with 0.8.3.  We just haven't ported everything to the new architecture, yet.

    Yes, I believe we'll also be supporting indexers in classes, or at the very least, being able to override the default indexer.  This would mean that any property access after that would have the overridden return type.  We'll likely post more information about this closer to release.

  • Tried the 0.9.0 build, debugging and generics works fine, but where is overload on constants? Pressing F12 on "document.createElement" navigate me into "lib.d.ts" which only have one createElement (the default one) defined.

  • @horeaper

    I'm not sure if the libraries have moved over to using the overload on constants, yet.  The best way to keep up to date on the progress is to watch the repo, and then update after the changes go in.

    Overloading on constants should be working in your own code.  Also, there are some ongoing bugfixes here, so be sure to update your language service regularly to track those improvements.

  • Should be noted that 0.9 Alpha installs itself to

    C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\TypeScript,

    and not

    C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\xxxxxxxx.xxx

    as noted in the "Trying the latest typescript build".

  • Generics and better type inference.

    Hope all the interface definitions catch up as well.

  • This weekend I tried using 0.9.0.alpha, re-writing a couple of files in a JS codebase of ~50K lines in ~250 commonJS modules.

    Aside from one thing (see below) it was a pretty positive experience. I can see a way forward where I start at the low level, converting utility modules into TS, and then tackling higher-level files that consume them, so gradually there is more and more static typing. It's going to be practical to apply it gradually, which is of course essential in a working codebase.

    The main problem right now is the intellisense compiler. In my experience with this version, it rarely agreed with the 'real' compiler, so I spent a lot of time figuring out what I'd done wrong only to find that the real compiler had no problem with my code. Similarly I was (mistakenly) disappointed at how little type inference seemed to be happening - when in truth there was a lot happening in the real compiler! It just wasn't working in intellisense. The upshot is that right now I don't want to demo what I attempted to my co-workers because I'd have to "talk around" the intellisense so much.

    This lag between the two is unfortunate given that the intellisense feedback is going to be the main way people try to learn, and would also be the most immediate advertisement for the benefits of static typing.

Page 1 of 2 (27 items) 12