DataView and other interfaces missing from lib.d.ts

[basarat]

Looking at history : https://github.com/Microsoft/TypeScript/commits/master/bin/lib.d.ts

Was there on April 11 : https://github.com/Microsoft/TypeScript/blob/6f1feffe6710a3201fb46a0b01e16051bfc18a29/bin/lib.d.ts#L1689

Isn't there on April 18: https://github.com/Microsoft/TypeScript/blob/b8ebf561f94ea27ecfc6af3c2b20661e6fcd79ed/bin/lib.d.ts

Report by Atom-TypeScript user @vaughnroyko

The following code now fails (source from : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DataView):

var littleEndian = (function() {
  var buffer = new ArrayBuffer(2);
  new DataView(buffer).setInt16(0, 256, true);
  return new Int16Array(buffer)[0] === 256;
})();
console.log(littleEndian); // true or false

[zhengbli]

They are removed from extenstions.d.ts at #2739, as they are not used in the IE dom any more. See #2698. Although they should exist in the ES6 es6.d.ts.

[basarat]

Although they should exist in the ES6 es6.d.ts.

shouldn't they either exist in both or not exist in either.

as they are not used in the IE dom any more

I still see it in http://people.mozilla.org/~jorendorff/es6-draft.html#sec-dataview-constructor and I still see it in my IE (v11).

Using these API is not the same as targeting ES6 as far as I understand. But then again I'm not the one suffering here, just channelling :)

[zhengbli]

My understanding is it is only defined in ES6 spec. And to clarify, the "not used in IE" bit I mentioned is referring to that according to the new IE spec files, these types won't be used by any other dom types in the next version of IE. @mhegazy, do we separate "using ES6 APIs" with "targeting ES6"?

[mhegazy]

The definition in lib.es6.d.ts for matches the ES6 spec. it does not match the definition in existing engines today. Nothing stops us from moving them to lib.d.ts instead. but that still means that IE11 users will get errors.

The issue is with TypedArrays (Int32Array for instance), i believe ArrayBuffer and DataView should be safe to put back.

As a work around, you can either copy the definition from https://github.com/Microsoft/TypeScript/blob/release-1.4/bin/lib.d.ts in a local file in your project. or copy the whole library and include it in your project.

[mhegazy]

should be in master now.

[basarat]

@mhegazy Thanks. But as I said in the title there are others Since I am not the one suffering from this I'd like to bring in @cmichaelgraham who feels that there is stuff in lib.d.ts that should be there but is no longer there. It is there in lib.es6.d.ts

[cmichaelgraham]

fyi - just finished deleting ~360 lines in lib.es6.d.ts and about 12 lines in lib.core.es6.d.ts so i could get a successful compile of an aurelia app in atom-typescript.

repo is here

i copied lib.es6.d.ts because i was getting tons of errors about ...rest parameter must be an array (even though it had any[] as its type) and couldn't find Function type (and other errors too).

i copied lib.core.es6.d.ts because it couldn't find HTMLElement type.

[basarat]

@mhegazy basically he's needed to copy https://github.com/cmichaelgraham/aurelia-typescript-atom/blob/master/skel-nav-ts/typings/lib.dom.d.ts.xxx into the project. Is this desirable? I think this stuff belongs in lib.d.ts?

Specially since its in libes6. Either it should be in both on in none. Thanks! 🌹

[mhegazy]

@cmichaelgraham what were the types you needed from lib.es6.d.ts and were not in lib.d.ts? do you have a list?

@basarat We can move ones that are known to work in pre-ES6 world, so any thing that has symbols for instance can not move. similarly, promises, proxy, reflect..etc..

[cmichaelgraham]

@basarat - is there an easy way to export the build errors from Atom-TypeScript? I could replace the .d.ts files and generate an error report. short answer @mhegazy - i don't know...

[mhegazy]

@cmichaelgraham it does not have to be complete. we can start by some errors :)

[cmichaelgraham]

ok, sounds great !! to make sure i understand the ask, this is the typings folder in my repo. if i understand, i should remove the .d.ts files in this folder (not the child folders), and add this .d.ts file, and then report the type errors i get when building?

[basarat]

Definitely typed has massive errors (DefinitelyTyped/DefinitelyTyped#4101 (comment)). bringing in @vvakame :

Node:

For node.d.ts to work we need :

DataView (didn't make it into beta) < this will probably fix itself :)

Map
Set
WeakMap

[zhengbli]

This is because the new dom.generated.d.ts has added many types that were previously defined in DefinitelyTyped already. From the error log it seems webaudioapi/waa.d.ts and touch-events/touch-events.d.ts are the most affected file. I'm investigating these two files.

[vvakame]

I want to writing es6, and emitting by es5.
I need Promise and Map, Set and others...
I think we should make better handling to diff of lib.d.ts to lib.es6.d.ts.

[mhegazy]

The reason they were split is that we got feedback that the library contains definitions for things that are guaranteed not to work in the wild, unless you have a pollifill (e.g. promises and symbols).
I think if you are using promises, you are including some promise library, be it Jquery, or qpromise..etc.. you should be including a .d.ts for it which will define these. similarly for Map and Set. Adding these typings to the library makes it hard for you to include the other .d.ts (redefinition errors, definitions do not match that of the library.. etc.)

I would like to get your feedback as well, do you think its better to have one library?

[basarat]

Beginning to feel like any form of global namespace in JS is a bad idea. Don't have a good answer :D

[ifeltsweet]

Map, Set, WeakMap are still missing.

[vvakame]

I like to unified default library.
I think mv lib.d.ts lib.es5.d.ts ; mv lib.es6.d.ts lib.d.ts is good.
--target es3, es5 and es6 are use lib.d.ts usually.
Node.js does not have document.getElementById and PhantomJS(1.9.8) does not have Function.prototype.bind. I think it is difficult to do well in all environments.

[basarat]

Its making its way to stackoverflow http://stackoverflow.com/a/30020614/390330

[basarat]

I think it is difficult to do well in all environments.

I agree. A single .d.ts with the responsibility of polyfill being on the user. Perhaps we don't want the target to control the ambience.

[duanyao]

@mhegazy

The reason they were split is that we got feedback that the library contains definitions for things that are guaranteed not to work in the wild, unless you have a pollifill (e.g. promises and symbols).

I think this reason is simply invalid, because:

• TS isn't informed enough to figure out a set of APIs that "guarantees code to work in the wild". If TS really want to do this, it has to import data from something like caniuse.com and ES6 compat table.
• A common practice for cross-platform is feature-detection, however without definitions in lib.d.ts the code won't compile. Additionally, it is hard or impossible for TS compiler to figure out whether a piece of code is protected by feature-detection, or won't run in cross-platform way.
• Not everyone has to guarantee they code to run on every platforms. Firefox/chrome extensions, Windows store/node.js/phonegap/xulrunner/node-webkit/atom-shell applications are examples. It is ridiculous to let TS instead of developers to make the decision whether particular ES6 or HTML APIs should be used or not.

So I think even if it is desirable for some users to disable ES6+ APIs in ES5 mode of TS, there should be an option in tsc to get them back.

See also discussion here #3211 .

Adding these typings to the library makes it hard for you to include the other .d.ts (redefinition errors, definitions do not match that of the library.. etc.)

This is another issue that TS should address, see #3215 .

[mhegazy]

@duanyao please see my comment in #3211, and i think we need to keep the discussion in one issue, just to avoid duplicating comments across issues.

now for your comment.

TS isn't informed enough to figure out a set of APIs that "guarantees code to work in the wild"

That is absolutely true, and this is why we do not want to be in the business of telling you what works and what does not. All what TypeScript compiler needs is type definitions, which are available as per ES6 spec in lib.es6.d.ts, the question is should we included by default in every compilation, and in editors like VS, sublime, VS code, atom, etc.. when you open a new file? we did that in TypeScript 1.3, and got feedback that ppl have found that confusing, so we kept them out. Nothing stops you from adding the file your self, adding a totally different file because you have some custom definitions, augmenting them...etc.. issue #3215 should make that even easier when fixed.

I believe a solution that would give everyone what they want, is a new --lib flag, that allows you to specify which lib you want to use. Also please see my comment in #3238 (comment)

[basarat]

I believe a solution that would give everyone what they want, is a new --lib flag, that allows you to specify which lib you want to use.

Sounds like a plan 👍

[wholroyd]

So where is the new flag or when should it be expected? I'm getting compile issues for DataView, Map, Set, and WeakMap from the node.d.ts TSD typings file. What is the workaround?

[enlight]

@wholroyd

I'm getting compile issues for DataView, Map, Set, and WeakMap from the node.d.ts TSD typings file. What is the workaround?

Put a copy of lib.es6.d.ts in your project, that has the missing types.

[wholroyd]

I don't see a lib.es6.d.ts anywhere, but I do see a lib/es6.d.ts here. Is that the same file?

[enlight]

@wholroyd https://github.com/Microsoft/TypeScript/blob/master/bin/lib.es6.d.ts
Or you can grab the one that was shipped with the TypeScript version you use from a source zip on the releases page.