
Announcing TypeScript 2.7 - DanRosenwasser
https://blogs.msdn.microsoft.com/typescript/2018/01/31/announcing-typescript-2-7/
======
ComputerGuru
TypeScript is a great improvement over JS, still held back by the horrible
state of the JS module system in browsers. You write your code and it does
what you want, then you spend a month figuring out amd vs esnext vs systemjs
and Babel vs browserify vs requireJS vs webpack vs god knows what else.

And then when you find the solution that works.. two weeks later it is
deprecated, the docs are gone, there is no clear migration path, and there are
only conflicting blog posts full of misinformation by people that only know
what worked for them and don’t actually understand what it is that their steps
actually do or how they work.

(Yes, as you can tell I did not start off life as a JS web developer.
TypeScript made the development part palatable to me, but the deployment
remains a nightmare as far as I can tell.)

I wonder if the TS team has explored using webasm to at least get around the
compilation/translation issues.

Edit: I actually know the difference between the technologies I mashed into a
single list (they’re not arcane concepts in low level development, it would be
akin to confusing make with clang++ with gdb with Linux with ARM). I didn’t
bother spelling it out because it’s not the point (I don’t have a specific
question) and because to too many people that is what it seems like.

Edit 2: Please see my reply to @coltonv below:
[https://news.ycombinator.com/item?id=16278062](https://news.ycombinator.com/item?id=16278062)

~~~
Raphmedia
Come on, take the time to learn your tools instead of blindly mashing things
together.

Step 1 : npm install --save-dev gulp-typescript-babel

Step 2:

var gtb = require('gulp-typescript-babel');

gulp.task('compile', function () { gulp.src(config.typescript)
.pipe(gtb({incremental: true, configFile: 'tsconfig.json'}, {presets:
['es2015']})) .pipe(gulp.dest(config.output)) });

Step 3: Enjoy.

~~~
paulddraper
> instead of blindly mashing things together

...immediately mashes a massive number of things together

~~~
Raphmedia
Since when is using two libraries (typescript and babel) considered mashing a
massive number of things together?

If you don't want to leverage Gulp to easily automate your build process then
don't.

If you don't want to use NPM to download packages then simply download the
.zip archive on Github,

~~~
paulddraper
(1) It's three: gulb, typescript, and babel.

(2) It's hundreds more

    
    
        $ npm install
        $ jq '.dependencies | length' < package-lock.json
        176
    

IDK what "blind mashing" would be if not this.

~~~
Raphmedia
Do you count the number of vendor DLLs when you develop .NET applications
using third party libraries? Of course libraries will have dependencies.

You are only "blindy mashing" three libraries here. Gulp to manage your
workflows, Typescript (because that's the goal of your workflow) and Babel to
allow older browsers to read modern Javascript. You can cut Babel out of it if
you develop something for a modern browser (internal apps, mostly).

That's three widely used dependencies. There is nothing obscure about them at
all. The only questionable choice in that tooling chain is Gulp. The reason I
used gulp here is that it's very easy to use it to output simple Typescript.
Something such as Webpack and Browserify would be for bundling modules and
that's an advanced topic.

------
deeg
I'm a back-end developer (Java, Scala, some Rails) and when I first heard
developers were using Node+JavaScript as a server stack I thought they were
nuts to use a dynamic scripting language for enterprise software. TypeScript
has a chance to turn that around, though, and might be the future: a mostly-
typed language that also has the flexibility to be dynamic when called for.

I really like TypeScript and it has ushered me into the node environment.

~~~
maxxxxx
Same here. I had to take over a node project and I can't imagine how anybody
could maintain a large JavaScript codebase long term. It's way too easy to
insert a simple mistake. The next version of our project will be slowly ported
to TypeScript and I look forward to it.

~~~
jondubois
The root problem is that most companies don't spend any time planning their
projects. It should only take a couple of days and yet companies just don't do
it.

The bad coding style that you sometimes see in JavaScript land is just a
symptom of a greater problem that static typing masks but doesn't actually
fix.

I like dynamic typing because then I can see straight away if the project is
crap or if the team is crap.

~~~
maxxxxx
I think Javascript is definitely way too forgiving. I just had a situation
where a property name was mistyped. The value was "undefined" which then can
be compared against strings. So the code worked without warnings but the
results were wrong. Took several days to track this down in a long promises
chain. With a typed language this wouldn't even have compiled.

~~~
jondubois
But with JS you don't need to wait for your code to compile so you can test it
much quicker. If you write tests then this is almost never a problem.

With typed languages, I often lose my train of thought while waiting for the
compiler. When warnings come up, I'm like a robot, I don't actually think, I
just follow the line numbers.

Statically typed languages make me lazy. I feel like I spend all my time and
mental energy catering to the compiler. I like dynamically typed languages
because it forces me to consider everything and keeps me on my toes.

~~~
mixedCase
You can't type things properly without considering the business logic. Once
you have that figured out the correct logic comes easily.

The compiler should be sparing you from wasting mental energy on menial things
by telling you what to do, even when making large changes that would be
disgustingly complicated in a dynamic language.

If you feel like you're "catering to the compiler", then you're going about
things wrong; because you're worrying about logic before nailing down the
proper data structures.

------
whitefish
On the one hand I am glad they are continuing to enhance TypeScript. On the
other hand I am concerned that TypeScript is becoming a very bloated language.
If you have seen the latest edition of Stroustrup’s C++ Programming Language
book you know what a bloated language looks like. Is that where TypeScript is
headed?

Programming languages are not like your Word or Excel where more features is
better. Some programming language designers take pride in how small the
language is, for example Kernighan and Ritchie. I worry that as long as
Microsoft has Program Managers and Development Leads assigned to TypeScript
and their job performance is measured by the number of features they add,
TypeScript is going to get more and more bloated with obscure features.

~~~
buu700
TypeScript itself doesn't really add new language features; it just tracks the
ECMAScript spec and considers proposed features for implementation after they
hit stage 3.

The enhancements coming out in new TypeScript releases are largely related to
typing expressiveness / type inference precision (covering more edge cases
where one might have previously resorted to `any`) and strictness (catching
more errors at compile time).

~~~
jsheard
Indeed, the only Typescript feature I can think of that isn't purely for type
checking or lifted from ECMAScript is Enums, and Enums have been around
forever.

~~~
camus2
Well it has supports for JSX and decorators which AFAIK aren't in the spec
yet. It also has a syntax for class mixins without actually doing any
desugaring when the code is transpiled. So it's not quite just JS + types.

~~~
jsheard
Ah, I forgot about those. Nonetheless JSX and Decorators were added to the
language back in 2015, so they've been sticking strictly to ECMA features for
nearly 3 years now.

------
lhnz
Personally I've moved away from the TypeScript compiler and towards the betas
of `babel@7` and `@babel/preset-typescript`
([https://www.npmjs.com/package/@babel/preset-
typescript](https://www.npmjs.com/package/@babel/preset-typescript)).

It seems to be faster and there is better integration with `jest`, `rollup`,
various css-in-js libraries and (maybe in future?) `create-react-app`. (I
still run `tslint` and `typescript` in the background for type-checking and
linting. And I've written a tiny CLI to generate flat `index.d.ts` files to
share my packages.)

The one thing I still miss about JavaScript is the possibility of writing
codemods to speed-up upgrades. Unfortunately, in order for `jscodeshift` to
support TypeScript, I think there would need to be some further work on
`recast`
([https://github.com/benjamn/recast/issues/424](https://github.com/benjamn/recast/issues/424)).

Hopefully the TypeScript team will continue to work closely with the Babel
team, since this would be very good for the eco-system.

~~~
mpawelski
I'm not sure if I understand fully this babel <-> typescript integration. Can
you help me understand this?

What's the point?

So in future babel would be able to parse TS file and output JS file with all
the transformations it supports? So it's useful if you want to use some new
EsNext feature currently not supported by TS compiler?

Is this the main advantage? Because for me it looks like a pretty weak reason
(TS has improved a lot when it comes to supporting new ESNext features).
Anyway, from what I understand TS provide API that for example webpack loaders
use (like [https://github.com/TypeStrong/ts-
loader](https://github.com/TypeStrong/ts-loader) and
[https://github.com/s-panferov/awesome-typescript-
loader](https://github.com/s-panferov/awesome-typescript-loader)) and it looks
that those can be integrated with babel.

Or is it mainly to support tools that depends on babel for parsing AST? And
microsoft is willing to maintain this babel integration for next versions of
TS? So non-microsoft community developed tools can easily add support for TS
(instead of only supporting JS), like Prettier did
([https://github.com/prettier/prettier/issues/13](https://github.com/prettier/prettier/issues/13))?

But are everyone using babel for JS parsing? I'm not that into JS tools
community, and am a bit confused by all this ESTree, Esprima, recast,
jscodeshift projects and relationship between them. You mentioned `recast` TS
support and it looks they want to use babel for this too. So it's microsoft
bet that all future JS tools that need to parse JavaScript AST will use babel
for that, and hence they will add TypeScript support because it would be easy?

~~~
lhnz
For example, the React team provide a set of codemods to help automatically
upgrade codebases when there is a new version of React
([https://github.com/reactjs/react-codemod](https://github.com/reactjs/react-
codemod)). Until `recast` gets TypeScript support, everybody who uses
TypeScript has to do this repetitive work manually.

Another example is how many `css-in-js` libraries require Babel plugins to
work their best (e.g. [https://github.com/emotion-
js/emotion/tree/master/packages/b...](https://github.com/emotion-
js/emotion/tree/master/packages/babel-plugin-emotion)).

And additionally there are also plugins that optimize React code (e.g.
[https://github.com/thejameskyle/babel-react-
optimize](https://github.com/thejameskyle/babel-react-optimize)).

------
jsheard
Class property initialization was always a glaring blind spot in Typescript,
I'm glad to see that strict mode verifies it now.

Thanks to the Typescript team for making Javascript much more tolerable :)

------
matchbok
Awesome. Making JS better every day. For any medium+ sized project, plain JS
just falls apart. Thanks guys!

------
AriaMinaei
TypeScript 2.8, due next month, is shaping up to be an interesting release! It
introduces a feature called "conditional types [0]" which opens up a lot of
type-level programming opportunities.

Flow also has the `$Call<>` type (type-level function application), but
unfortunately as with most of its features, it didn't go through community
testing/input before release, and thus it has bugs that render it useless for
what I assume to be very common use-cases.

[0]
[https://github.com/Microsoft/TypeScript/pull/21316](https://github.com/Microsoft/TypeScript/pull/21316)

~~~
mpawelski
Just curious, what are the problems/bugs with `$Call<>` that you are talking
about? note: I only used TypeScript, not Flow)

~~~
AriaMinaei
I think this demonstrates some of the bugs:
[https://flow.org/try/#0PTAEAEDMBsHsHcBQiCWA7ALgUwE6QIYDGWoAS...](https://flow.org/try/#0PTAEAEDMBsHsHcBQiCWA7ALgUwE6QIYDGWoASlkRigG5YDyARgFYA8dAXKAN4C+AfN0ShQABxywRLANKcAJFKwBPAM5s+fABRSAlHIDC+aNBYARLIRQATLABVFIrABpQsgKLQsAWyyY7Dts5S6og8yOjYeEQk5JQ0WACCODj4iiwAagJcQqDo1gAeGmgArp4MuLouBkam5la29k6gGSFhmLgExGQUhFS0AEKweemZ2UVoDIMaFWktiBgNoGYW1n4kALzZAGSgGmycvJp02qBrAjE9cYysdHzaWzvpzvGcicmpGZrxx6ddsbSvKWGd2E212GQ0aW+Z26vSwAyGGW0AG5kPMHKAbFhlBgruYMCdBMJsThOMT0ABzRzZWDMfbZIkYHAASTQV1JjIpVOEwmKpVwLLZoF5ZRwXO5+CSKQFtNAANSwtwfDFoR4KLmC0x2NxPXOVEgKCwlgJsiqxiWdVWzk1OOYeL4aushGgEpI1AloGwWpl1u1GF1KH1hrVGk9NqYADoxBINAByYkxir+-qDFhktDk25qkAuABicHgrjyDh6riSsBwGIAFihlKBoOgSIR8EVlFiPfBYKBWyIJfhsKBcOIcMpnLA0NBFKAxyRYJBQPBq4RK6ByVgMLXlCgPGhiJZECGsWHI+IRLH44mYXF4SwFThM8hszZqxvK7AitAjWhYPiyqB8GgBzLUVQAYIp8RQcDlHYfdQyuY9oxjGkmATeDTzjRlpWQ7RkQfMAnxrLtX3fI1DGUTse2UEcQLAnJ8UsWAsTQGMMGgg8vQjKM0KQlDONjW9MITTgkzhFNb3vRBs1kPMEELYsMFLIcqwIwdyyo0D8UgcsPUrEh4HEdNQBwCgyLQVjYOYVDY247RLJjfjWWYQTfguZMhjTDMcKAA)

------
013a
I wonder if there was ever a discussion that definite assignment assertions
should have a strict mode flag to disallow. They seem like something that can
be abused to escape the static type system.

~~~
smt88
I use tslint to disallow practices that TS has no compiler flag for.

~~~
WorldMaker
You don't even need to run tslint as a separate process these days. tslint
supports running as a TS plugin, and will report its errors and warnings
directly in the TS compiler output.

------
sandeepc24
I have used TypeScript and I liked it but now I prefer to use Fable
[http://fable.io/](http://fable.io/)

I agree with others that a language should not become bloated and I think it
is heading in that direction.

------
nimos
No incremental compiler? I thought that was coming in 2.7. Really hope that
lands soon. Compile times are my only complaint about TS, otherwise it is so
much nicer than writing JS for anything mildly complex.

~~~
mceachen
TS 2.6's `--watch` support became wicked-fast. In medium-sized repos (50klocs)
the compiler is done in the same second it wakes up from the fsevent that a
file changed.

~~~
nimos
Ah nice thanks, must have missed that announcement. Do you know offhand if
that works with a webpack toolchain using one of the ts loaders? Haven't been
doing much web stuff lately and last version I've used was 2.5.

------
singularity2001

        static readonly StaticSymbol: unique symbol = Symbol();
    

just no!

------
jondubois
My favourite feature of TypeScript is that it supports dynamic types.

I hope that in the next version they will improve support for dynamic typing
even further by disabling static typing.

~~~
echelon
Dynamic types cannot be automatically refactored.

Dynamic types often incur the need for additional testing.

Static types can be verified at compile time.

Static types rarely lead to runtime type errors.

------
dfgin
Nvm. ESxx is already waaaay too bloated, and Typescript only adds to that. All
those new features are only adding complexity, pain and bugs. I'm curious when
we arrive at the point when it's less painful to write a web app in C, it
feels we're getting quite close already!

I try to keep my codebase as simple as possible with Coffeescript, doing
dynamic type checking with types.js. Honestly very rare to see a type related
bug in my codebases.

For all those ESxx and Typescript proponents out there: You don't need it. It
doesn't make your life easier at all. In the Javascript domain I wind down as
much as possible on the endless libs and tools to keep my codebase readable
and my mind healthy.

------
jondubois
I have an idea for the next version of TypeScript.

Instead of compiling directly to JavaScript, it should compile to CoffeeScript
first and then to JavaScript - That's a great feature I'd love to see.

Of course, this feature wouldn't be possible without also adding support for
meta-source-maps (aka source-map-maps).

That way we can experience the pleasure of debugging in 3 different languages
at the same time.

~~~
AgentME
I know it's a joke, but the thing about sourcemaps is already do-able. If you
have a sourcemap describing A->B, and a separate sourcemap describing B->C,
then there already tools for composing the sourcemaps to create a sourcemap
for A->C. (This is similar to a thing that Browserify and Webpack have to do
when you're using a transform like Babel on each of the individual input
files.)

