23 ms·

Announcing TypeScript 2.0

• velmu 10y ago
  Aweyissssss!
• oblio 10y ago
  Highlights: * npm replaces typings/tsd * non-nullable types (has to be switched on) * better control flow analysis (à la Facebook Flow) * read-only properties
• k__ 10y ago
  TL;DR - Simplified Declaration File (.d.ts) Acquisition (via npm) - Non-nullable Types - Control Flow Analyzed Types - The readonly Modifier Finally, I was wating for months :)
  • wereHamster 10y ago
    And a whole lot more. https://github.com/Microsoft/TypeScript/wiki/Roadmap https://github.com/Microsoft/TypeScript/wiki/Roadmap has a summary of the most important changes.
  • novaleaf 10y ago
    i hope they will add details on creating new d.ts files for the new @types scope.
    • DanRosenwasser 10y ago
      We've got some of the documentation out now. You can see more at https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html https://www.typescriptlang.org/docs/handbook/declaration-fil.... When submitting PRs, new files will need to be written for the `types-2.0` branch on DefinitelyTyped.
      • animesh 10y ago
        So now tsd install angular is replaced by this? npm install -s @types/angular
        • k__ 10y ago
          As far as I know, some libraries bring their own typings, especially when they're written in TypeScript.
          • WorldMaker 10y ago
            Right, Angular 2 could build typings directly from their Typescript sources into their npm packages (there's a "typings" field to add to package.json being the only other step). If they did that all you need is npm install -s angular and typings just fall out of the sky for you. Aside, my biggest concern with the new @types scope is that it is still tightly coupled with the DefinitelyTyped megarepo. DT has been a great help over the years, but it's so huge and increasingly hard to contribute to as DT has increased its quality bar and its size makes it a stress test on git tools and IDEs, too.
        • the_duke 10y ago
          If the library has it's own .d.ts file in the repo, it will just work. Otherwise, the @types packages on npm are the way to go. Please note that most of the @types/XXX packages are just automatically extracted from the DefinitelyTyped repo. Big packages with lot's of updates can use their own repo. But this is a huge, huge usability win. No more haggling with additional tools to get your typings.
          • tga 10y ago
            From a usability point of view is it really such a huge huge win that instead of using `typings install foo` you can now use `npm install @types/foo`? I can see it's better (not sure why a single repository(!) was ever considered a good idea), but in the end both methods work if all you need is to obtain the latest version of a .d.ts file.
  • FrancoDiaz 10y ago
    Simplified Declaration File (.d.ts) Acquisition (via npm) This is huge from a usability perspective.
    • ng12 10y ago
      It doesn't seem to be ready. Random thing are broken that weren't in Typings.
      • FrancoDiaz 10y ago
        There's a couple different things we're talking about here. The ability to install typings via npm, which is good because it gets rid of another tool (typings) and everything is in package.json. But the other thing is the ability to consume declaration files in node_module packages themselves, which I consider a bigger win.
        • ng12 10y ago
          Why couldn't you do that before? Definition files are just ts files, wouldn't tsc be able to find them in node_modules?
  • FrancoDiaz 10y ago
    I'll add the ability to use globs in tsconfig is a big win too. http://www.typescriptlang.org/docs/handbook/tsconfig-json.html http://www.typescriptlang.org/docs/handbook/tsconfig-json.ht...
• sdegutis 10y ago
  > In TypeScript 2.0, null and undefined have their own types which allows developers to explicitly express when null/undefined values are acceptable. Now, when something can be either a number or null, you can describe it with the union type number | null (which reads as “number or null”). Great news, but I suspect it's going to be pretty difficult to migrate large codebases to account for this properly, even with the help of `--strictNullChecks`. Sounds like days worth of tedious work analyzing every function.
  • klodolph 10y ago
    Yes, although the same can be said for the "no implicit any" flag when migrating from code bases EcmaScript. They seem to be doing a pretty good job of supporting both legacy and greenfield projects.
    • k__ 10y ago
      Yes, I tried "no implicit any" and got nothing working. Problem were mainly 3rd party libs with out-dated, bad or no type definitions. Is it even possible to use these flags with production code?
      • RyanCavanaugh 10y ago
        We've removed nearly all the implicit anys from DefinitelyTyped, so if you're getting definitions from there, you shouldn't see any. We don't have good data on this but my perception from talking to people on GitHub is that the vast majority of people using TypeScript run with 'no implicit any' on once they get their codebases converted. (I'm on the TypeScript team)
        • k__ 10y ago
          Nice to read :) Had some problems with React/JSX back in the days.
        • johnny_reilly 10y ago
          And even if noImplicitAny in 3rd party libraries is not honoured you now have: skipLibCheck which will limit checks to your own code. Details here: https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option... I believe it's actually a perf gain to run with this set (but I'm not certain).
• edroche 10y ago
  I can't wait to use some of the new features in our production apps. Typescript is/was my bridge into javascript development, because IMHO javascript was a broken language for a long time, and I am not sure if I could have ever done as much as I have without its existence. Non-nullable types, tagged union types, and easy declaration file acquisition are definitely the biggest wins for me with this release.
  • nikolay 10y ago
    Well, to make JavaScript tolerable, you need to use Babel with tons of plugins and presets. Instead, you can just use TypeScript.
    • woah 10y ago
      Still no async/await though, right?
      • vmasto 10y ago
        No the spec is finished and Babel supports it. Browsers already have started implementing it. Edit: I realize you mean Typescript, my apologies
  • qwertyuiop924 10y ago
    Javascript isn't as broken as you might think. Non-nullable types, OTOH, might just be the thing that makes me start using TS, despite my love of dynamic typing.
    • niieani 10y ago
      Try adding 1.3 + 1.1 and tell me JavaScript isn't broken. Hint: The result is isn't 2.4, it's 2.4000000000000004. Unfortunately that's something TypeScript doesn't tackle, but you can use external libraries for floats, where you work on floats as... strings.
      • 10y ago
• equasar 10y ago
  Awesome release! Yet, I'm still waiting for 2.1 to bring finally async/await generators.
  • kimsk112 10y ago
    Have you tried transpiling to ES6 and then use Babel?
    • egeozcan 10y ago
      It's "yet another 'transpilation(?!)' step". I currently use this combination but I would be way happier with just Typescript as in the current config the lag becomes noticeable.
      • kimsk112 10y ago
        If you use webpack, you could just add ts-loader as a first loader and babel-loader as a second one. Source-map works great too.
        • johnny_reilly 10y ago
          Yup - though you need to make use of lib if you want to write es2016 TypeScript and have Babel transpile it. Not too hard to get set up though: http://blog.johnnyreilly.com/2016/09/typescript-20-es2016-and-babel.html?m=1 http://blog.johnnyreilly.com/2016/09/typescript-20-es2016-an...
        • nippur72 10y ago
          before typescript@next I had exactlt that setup, but sourcemaps were broken despite all my attempts to make them work. Now I'm using ts 2.1 and have completely removed babel out of my build.
    • saosebastiao 10y ago
      I've gone that route for a while now. It's a nightmare of fragility in your build, not to mention little things like how it totally kills your sourcemaps. I just upgraded to typescript@next and it has been a dream. I eliminated like 50% of the cruft around my build just by doing that.
• dested 10y ago
  This isn't really the place for it but I really wish that both Webstorm and Resharper used the actual typescript compiler for its tooling (like vscode) vs handrolling their own. Now I have to wait until Webstorm 2016.3 to see the full benefit of 2.0, rather than getting it for free by just updating typescript. Not to mention the obscene number of typescript edge case inconsistencies in the warnings, errors, and refactorings.
  • CraigJPerry 10y ago
    You've been able to configure your own tsc for a while, at least in IDEA anyway.
    • jffry 10y ago
      Webstorm does as well. It's in the settings, under Languages > Typescript. You have set "TypeScript version" to "Custom" and give it the path to your "node_modules/typescript/lib", and then also check the box to "Use Typescript Service (Experimental)". It's marked as experimental, but has worked flawlessly for me on a moderately sized project using typescript 2.0.0@beta
    • dested 10y ago
      I more meant in the form of tooling, not compiling. The intellisense that it provides is often incorrect vs VSCode which asks tsc what the intellisense is, making it always correct.
      • jameslk 10y ago
        This is possible if you look closely at the settings for TypeScript in IDEA/WebStorm: > Select the Use TypeScript Service check box to get native support from the TypeScript Language Service according to the up-to-date specifications. In this case syntax and error highlighting is performed based on the annotations retrieved from the TypeScript Language Service while code completion lists contain both suggestions from the TypeScript Language Service and suggestions calculated by IntelliJ IDEA itself. https://www.jetbrains.com/help/idea/2016.2/typescript-support.html#d827982e95 https://www.jetbrains.com/help/idea/2016.2/typescript-suppor...
• Arnavion 10y ago
  Hmm... $ npm view typescript 'dist-tags' { latest: '2.0.3', next: '2.1.0-dev.20160922', beta: '2.0.0', rc: '2.0.2' } Yet https://www.npmjs.com/package/typescript https://www.npmjs.com/package/typescript says >typescript published 5 months ago >1.8.10 is the latest of 447 releases
  • FrancoDiaz 10y ago
    I guess that page just hasn't been updated yet. npm i -g typescript@2.0 will give you 2.0.3
• bsimpson 10y ago
  Control-flow analysis? I think that was Flow's differentiating feature. Obviously, there are still differentiators between the projects (like TypeScript including a known set of transpilers vs. Flow delegating to Babel), but I'm curious to know if they are converging on their core feature (e.g. how to do type-checking/static analysis).
  • shados 10y ago
    they are. Flow is still quite ahead in term of control flow analysis and "soundness" features, and the type system in general is much richer, but TypeScript is catching up. Flow's tooling is getting better (though it still has ways to go). It's pretty easy to see where things are going. Advanced type systems (Elm, Scala, ML, Haskell, whatever) have the features we really need, and tooling (IDE support, etc) can use that info to provide crazy good tooling, so any type system developed in 2016 and beyond must have all of these things to be of mass appeal.
    • DanRosenwasser 10y ago
      Hey, I don't see TypeScript as being behind on control flow analysis or anything like that. If you're referring to differences in the way TypeScript narrow types based on control flow analysis, we don't see one as being "better" than the other, but TypeScript takes a more optimistic approach to avoid putting users in frustrating scenarios where the analysis is too limited. Most users tend to prefer this to the slightly more rigid approach used in Flow, so we felt we made an ideal choice there. If you have any specific thoughts or ideas, feel free to leave us feedback on our issue tracker.
      • shados 10y ago
        To be fair, it is very, very unlikely that I am better at type systems than someone working on TypeScript, so anything I'd suggest, you probably heard about, and is either already on your roadmap, or was a conscious design decision that we just happen to disagree about :) I think the javascript type system world is still evolving, and the only "wrong" thing to do is to say "Ok, its a solved problem, let's run away with THIS ONE and kill the others". As long as we still have at least 2 reasonably well known ones, I'm happy.
• mhd 10y ago
  Seems the spread operator (a roadblock for a lot of JS interop) will have to wait until 2.1.
  • ihsw 10y ago
    I'm currently using the spread operator liberally. Why do you think it's unavailable?
    • shados 10y ago
      probably meant the object spread one, not array spread.
    • tomduncalf 10y ago
      It's available in JSX but not outside that scope, e.g. const { name, ...rest } = person; won't work
  • WorldMaker 10y ago
    ES2015 Object.assign() doesn't seem to me much more verbose than the not yet standardized object spread operator.
• macspoofing 10y ago
  Why choose "readonly" as the modifier for immutable properties? A little long, no?
  • RotsiserMho 10y ago
    Probably consistency with C#.
• ihsw 10y ago
  Still no async/await for ES5 build targets, but other than that a plethora of excellent new features.
  • mohamedhegazy 10y ago
    async-await transpilation for ES5/ES3 target is already available in the nightly drops of TS (`typescript@next`).
• leeoniya 10y ago
  class Person { readonly name: string; couldn't they have just reused `const`?
  • clappski 10y ago
    const means a completely different thing depending on what language you come from (even JavaScript). I think readonly has a much clearer meaning.
  • jameslk 10y ago
    From my understanding, const would mean the property would be immutable even within the class, where as readonly means it's only immutable when used from outside the class but still mutable inside the class.
    • judah 10y ago
      > "where as readonly means it's only immutable when used from outside the class but still mutable inside the class" Small correction: The readonly modifier means you can initialize the variable, but can't mutate it (even within the same class). For example, you can initialize a readonly field inside a constructor, something you can't do with const. Some good docs on it here: https://basarat.gitbooks.io/typescript/content/docs/types/readonly.html https://basarat.gitbooks.io/typescript/content/docs/types/re...
      • jameslk 10y ago
        It appears you're right: > Read-only properties may have initializers and may be assigned to in constructors within the same class declaration, but otherwise assignments to read-only properties are disallowed. Thanks for pointing that out.
  • RyanCavanaugh 10y ago
    `const` applies to a binding; `readonly` applies to a property. The difference is important because you can alias a mutable property through a readonly reference (thus observing two different values from the same reference if someone with a mutable handle on the object changes it), whereas a const will always have the same value because it's an immutable reference to a particular value/object.
• ggregoire 10y ago
  TypeScript is so strange for me. Each time I read something about it, I want to give it another try... then I read some codes and I just can't go further. I like JavaScript as it is, without types on every line of code. Unlike most people on HN, I like JavaScript. I build web app since 2011. I liked working with jQuery, then Backbone and Grunt, then Angular and Gulp. Now I'm working with React, Webpack and Babel (ES6/ES7) and writing web apps has never been so much pleasure. JavaScript in 2016 is really fine for me. And the common point in my JS experience from 2011 to 2016 is that dynamic typing has never been a problem. I also worked with strongly typed languages for years like Java or C# and I still prefer the flexibility of JavaScript. So it's strange because I admire TypeScript. The work accomplished by its team is really amazing. And it's so nice to see a single library reconcile developers with JavaScript. But in the other hand, I prefer keeping my JS without types because it just works fine for me and the teams with who I worked.
  • hasenj 10y ago
    Have you tried starting a fresh project with just TypeScript? I have no idea how your brain works, but for me working with a non-trivial JavaScript codebase is a nightmare. TypeScript makes web development fun again.
    • the_duke 10y ago
      Yeah. Every making even a small change to a JS codebase you haven't touched in a while that isn't VERY thoroughly tested? (Doesn't even need to be a big code base). Thinks will break. And you will lose hours of time. Static typing doesn't eliminate all bugs, of course. But it can catch many common mistakes made in JS.
      • pekk 10y ago
        If you don't have tests, why do you think your code works?
        • the_duke 10y ago
• jameslk 10y ago
  One of the things I've been really needing is buried in the wiki: > Previously flagged as an invalid flag combination, target: es5 and 'module: es6' is now supported. This should facilitate using ES2015-based tree shakers like rollup. So now I can add rollup to my production build pipeline to remove dead code. Nice!
  • jarjoura 10y ago
    Wow TIL, I had no idea this was a thing! It looks amazing!
• easong 10y ago
  I really wish that MS would release typescript as a collection of plugins for babel that would handle only one thing at a time (eg, the type system). Having my production build, es6 transpiler, type system, JSX compiler and so on (including a bunch of features I would rather didn't exist at all) all in one package feels like a failure of separation of concerns. I understand that people find Babel's plugin ecosystem confusing and intimidating (it is), but I don't think a separate monolithic typescript that reimplements popular babel functionality is the answer.
  • icholy 10y ago
    I agree, the javascript ecosystem needs more fragmentation.
    • easong 10y ago
      I suppose the problem is that I see typescript as the fragmentation. If MS leverages babel (they can even keep shipping TS as their own thing if they want, I just want them to provide babel plugins), we can all use that and focus on making it as cross-compatible and streamlined as possible. (Well, really, we can focus on providing a single well-documented on-ramp to new javascript developers, which I think is the main problem and the one MS set out to own with typescript.) Right now, we have the typescript ecosystem, the babel ecosystem, and the other wannabe ecosystems. If I like Typescript's type system but want to use babel for async-await (for instance, I'm aware it's in TS next), I'm basically SOL. Babel has more end-users (AFAIK), generally has the first/only implementation of <feature>, and my impression is that the surrounding development community is larger and more active (typescript stuff tends to come down from On High). For instance, you can use https://github.com/gcanti/babel-plugin-tcomb https://github.com/gcanti/babel-plugin-tcomb to get run-time type checking with babel/flow for free. That's really cool! Unfortunately, the same is not possible with typescript (AFAIK), because MS decided that was out of scope. If Typescript was offered as a babel plugin, somebody else could implement it for typescript and we could all be happy.
      • sotojuan 10y ago
• grimmdude 10y ago
  I gave TypeScript a try but honestly thought it was more trouble than it's worth in most javascript applications/libraries. Maybe that's just the lazy person inside me, or maybe my projects aren't big enough to make use of it's features.
  • jawarner 10y ago
    I'm curious specifically what friction you ran into.
    • the_duke 10y ago
      The biggest obstacle for Typescript by far is using libraries which have no or outdated declaration files on DefinitelyTyped. You can get good at writing the declarations yourself, but it's hugely annoying.
      • oldmanhorton 10y ago
        Well, you don't have to write any declarations -- everything will just be typed as `any`, which isn't preferable but is exactly what you'd get if you weren't using typescript.
    • grimmdude 10y ago
      Eh, I guess it was mainly the learning curve and lack of payoff. As mentioned here, I think my project size wasn't big enough for it to show it's usefulness.
  • seanwilson 10y ago
    I think you'd see the benefits once the code base gets big enough you can't fit it all in your head any more and the chance of mistakes rises rapidly.
• netcraft 10y ago
  I've got to find the time to play and get typescript set up figured out. I've had several false starts, always running into duplicate type definition issues and similar problems - looking forward to see if the new @types from npm help things.
• qwertyuiop924 10y ago
  Man, I feel like the only one here who doesn't really like static types. I like dynamic typing just fine (it's crazy, I know: it must be the lisp influence). And if I want static typing, TS feels a bit intrusive. Flow is much better in this respect. I also don't think JS is the root of all evil, and I use Emacs rather than an IDE (although we do have really good integration with regular JS, in the form of the famous js2-mode, and flycheck's linter integration). I, mean, do you really need your IDE checking your types as you type? It's not that slow, and us Emacs users have M-x compile, so we can run our code, and than jump back to the problematic line when an error occurs, and I know IDEs have similar functionality. Don't get me wrong: static typing can be good at times, and option static typing and compile-time type analysis are useful tools, and I'm glad TS, Flow, and the like exist. But I always see a flock of comments saying that they couldn't possible live without static types, and thanking TS for taking them out of the hell of dynamism, and wishing there was something similar in Ruby/Python/whatever. I don't really get that.
  • edoloughlin 10y ago
    Another Emacs JS dev here. I find Emacs + Tern works very well for me.
    • qwertyuiop924 10y ago
      Cool. Is it better than JS2?
  • moloch 10y ago
    Well TypeScript is sort of "optionally typed" (variables can have a type of `any`) it's also superset of JavaScript so any valid js is valid ts.
  • mschulze 10y ago
    My experience: I don't get how in a project with several developers and maybe even teams dynamic types work at all. If a colleague writes a function/method that returns something, in JS, how do I know what it is? I have to read the function or its tests. With a statically typed language I immediately know the structure of the returned "thing" (don't want to say object) and can infer how to work on it.
• HeyImAlex 10y ago
  Typescript is such a neat project. The js ecosystem is vast and diverse and the typescript team has the unique job of figuring out how to make common dynamic patterns type-safe and convenient. Like... that's so cool. Every little pattern like its own type system puzzle, and there's no _avoiding_ the issue like a ground-up language can do, because their job is literally to type the JavaScript we write today. Also, how much money is MS pumping into TS? A lot of OSS has one or two super-contributors that carry the project on their backs, but typescript has a small army of smart people with significant contributions.
  • IndianAstronaut 10y ago
    I'm still trying to figure out Microsoft's new end game. Major inroads into OSS, more linux support, VSCode, etc.
    • nojvek 10y ago
      End game is be relevant to developers. There's an entire org called DevDiv whose primary job is to win developer market share. If developers love your platform and tools, then they won't hesitate to use Azure and the other money making beasts.
• zem 10y ago
  typescript is a nicely conservative set of extensions to javascript, but if you're willing to venture a bit further afield, redhat's ceylon [https://ceylon-lang.org/ https://ceylon-lang.org/] is well worth a look. it has an excellent type system, and seems to be under active development, particularly in terms of improving the runtime and code generation. i played with it for a bit before deciding that for my personal stuff i prefer more strongly ML-based languages, but if i ever have to develop and maintain a large team project i'll definitely give ceylon a very serious look.
• smithkl42 10y ago
  Huge TypeScript fan here - been using it since its 0.8x days. And I'm very interested in the new --strictNullChecks compiler flag. But I'm trying to implement that on our current codebase, and I'm coming to the conclusion that it's still a bit premature. There are a lot of very common and harmless JS (and TS) patterns which this breaks, and for which it's been difficult (for me at least) to find a workaround. Turning on --strictNullChecks flagged about 600+ compiler errors in our 10Kloc codebase. I've addressed about half of those so far, and I can't say that any of them have actually been a real bug that I'm glad got caught. On the contrary, because of the weird hoops it makes you jump through (e.g., encodeAsUriComponent(url || '')), I'd say that our codebase feels even less clean.
  • evmar 10y ago
    One counterintuitive observation about introducing stricter type checking into an existing codebase is that it rarely finds bugs. Why? Because the existing codebase typically "already works", in that issues that the type checker might have found were already discovered through automated (or manual!) testing. The real value of more strict type checking is when writing new code -- you won't need to spend as much time discovering bugs in development or writing tests for issues the compiler is catching.
    • smithkl42 10y ago
      Good point. And I can see that I would have made different (and probably cleaner) design decisions in certain places if strict null checking had been a part of our code from the beginning.
• Roboprog 10y ago
  Does Typescript have a facility to support partial function application? Say I have a function of arity 4, and want to bind / partially apply (some might say "inject") 2 arguments to it to create a function of arity 2, can TS infer the types of the remaining arguments, or, that the result is a function at all??? I use partial function application MUCH more than classes in the JS code that I write. There just seems to be less to need all that "taxonomy" related refactoring. "Stop Writing Classes", "Executioner" in "The Kingdom of Nouns" (not!), and all that sort of thing :-)
  • Roboprog 10y ago
    For those of you unfamiliar with partial function application, it's a good way to replace many classes that consist of nothing other than a single "do the work" method and a constructor or setters for the configuration/dependencies with a single function. You put the configuration / dependency parameter(s) first, and the more "volatile" parameter(s) last. Rather than having a constructor call, you partially apply the things you want pre-bound (config, deps) to create a new shorter function that acts as the "do it!" method. E.g. - write a function to send emails. Put the "reply to" parameters first. Partially apply that data. Use the resulting function to send emails to specific people. Bind on the distribution list name argument. Use that function to send alerts to those recipients. Bind on the content of an alert. Use that to send an alert when needed, without having to come up with any of the input, just the 0-argument function. Overloading, alternate constructors, subclasses??? Screw that. As long as the parameter order is reasonable (least to most volatile), there is seldom anything to be "refactored" "Currying" just means that you apply a single argument at a time, until you get down to an "arity 1" function, after which the final argument runs the original function with the last remaining argument, rather than returning an "arity 0" function. Here is an example library that does A LOT of currying: http://ramdajs.com/docs/ http://ramdajs.com/docs/ If I apply/bind a function to my higher order function, is that dependency injection, or subclassing? Who cares. I like arity 0 functions. They make nice event handlers. I have been gradually converting to Javascript for the last 8 years. My paradigm has definitely shifted. I know how miserable static OOP is, and won't be going to my grave not knowing :-) (here's the quote: https://www.facebook.com/groups/nodejsis/permalink/1429400523804671/ https://www.facebook.com/groups/nodejsis/permalink/142940052...)