ES2015 Collection Type Definitions

[janslow]

Node.JS has used a V8 engine which has supported ES2015 Map/Set constructors since 2.0.0 so it would be useful if their definitions could be added to the node@4.0.0 definition.

The definitions themselves can probably be based on the definition in lib.es6.d.ts.

[blakeembrey]

Things get tricky here, since it's technically provided by TypeScript if you enable lib.es6.d.ts.

One thing I'm interested in is whether we want something that works with pure noLib, I do think that would be great.

[janslow]

I think that would be ideal, as it's unlikely Node will perfectly fit into an ECMAscript standard in the near future.

As far as I'm aware, it's not possible to use lib.es6.d.ts without fully targeting ES6/ES2015 in the compiler options . This has the issue that some ES2015 features which aren't supported by Node 4.x (such as default arguments), aren't transpiled back to ES5, so causes an error when run on Node 4.

I'll have an experiment with trying to merge the modular ES2015 lib definitions into node.d.ts and will create a PR if I find something useful.

[louy]

So the problem we have here, which is the reason why this will probably be done in a separate version/variation of the node typings and not the main one, is that you might get conflicts and break things for users who would use target: es7.

It's the same issue when using es6-promise typings with target: es6. It simply breaks your build and you can do nothing about it.

I'd love to see typescript allowing conflicts like that, but in the mean time, this will have to be in a separate declarations file probably called node-nolib or something.

We can still <reference /> the original file in the nolib version though.

Related: #1

[janslow]

That's a good point and it probably means this won't be fully solvable until microsoft/TypeScript#4692 is complete, to allow targetting platforms between ES versions in the TS compiler.

However, that issue is still at proposal stage and doesn't have a milestone release target, so I believe it would be useful to have an intermediate solution.

My thoughts are, if you are developing for Node.JS 4.3, you should target ES5 (the highest fully supported ES version, without any harmony options). You then use a node env definition to help fill in the gaps between ES5 and Node 4.3 (e.g., polyfills, collections).

As harmony options become core features across different minor versions, these definitions would need to target minor versions, as opposed to just targeting 4.x.

I'm not sure whether this solution belongs in this particular repository though, or in a repository called node-es5 (or similar), which depends on node@4.

Any thoughts on this idea?

[louy]

I know the problem with TS now, and why Console worked but Error didn't.

Everything in interface Console was a function. Typescript has no problems with functions as it treats them as overloads. But anything else (read: attributes) becomes a problem.

I've added interfaces for Map/Set etc in map-set branch. The only important thing that's missing is Map#size and if we find a workaround for it everything else should be fine.

[louy]

Actually, I found a workaround.

[felixfbecker]

We should also add Object.assign() to Node 5.