Create ES3 specific lib.d.ts

[SergioMorchon]

By targeting to ES3, the following code (within a class definition):

 setOptionDisable(option: HTMLOptionElement, operation: EnumOperations) {
 ko.applyBindingsToNode(option,
 {
 disable: BI_OP.has(operation)? this.selectedNumbers().length >= 2 : true
 }, item);
 }

compiles, but the item variable is not defined. Does really item exists in a ES3 standard browser? I wasn't able to find it, so I treated this as a bug.

[danquirk]

You'll need to post more repro code. Simply using an undefined name like that in a small snippet is clearly an error. If there's actually a bug in the compiler or your code it's more involved than just that function definition.

[SergioMorchon]

On the lib.d.ts file is defined the following function:

declare function item(index: any): any;

But as seeing @ http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf 15.1.1 Value Properties of the Global Object (page 77) and W3C http://www.w3schools.com/jsref/jsref_obj_global.asp , there isn't any item global function.

This misstake causes that if I use a non-defined ítem variable on my code, which of course doesn't exists, it will compile ok, but it shouldn't!

For example:

item();// must throw a compilation error. Instead, it is getting a runtime one on the browser because it is not defined.

Same with msClearImmediate, btoa, atob, etc.

I think I can't explain it better... :S

[danquirk]

Ah, we could consider an ES3 specific lib.d.ts. In the meantime you should just remove those members from the copy of lib.d.ts you're building against or polyfill the implementation if you're targeting both ES3 and ES5 and want that functionality everywhere. We already see most people targeting ES5+ and that's only going to increase so this isn't likely to be super high priority to fix right now.

[RyanCavanaugh]

Would probably accept a PR on a good es3.lib.d.ts

[SergioMorchon]

This is very interesting at Enterprise environments that works with legacy browsers.

[mhegazy]

related to #6974

[ericdrobinson]

I understand that this is a relatively old Issue, but I would like to toss in a use-case for providing an es3-specific declaration lib. I find myself working with the [admittedly aging] ExtendScript language, one that is primarily used for creating extensions to Adobe products. The language itself is ECMAScript 3-based.

It appears to be possible to write TypeScript such that compiled JavaScript can work with this language:

• Specify the "es5" lib in the compiler options (or whatever you wish to write in).
  • Omit the "dom" lib.
• Set the target compiler option to "es3".
• Provide declaration files for other ExtendScript types.

However, it is not possible to write type-annotated ExtendScript in a TypeScript enabled environment. With a lib.es3.d.ts declaration file option, this would be possible with very little change to the above configuration:

• Specify the "es3" lib in the compiler options. [<-- Missing!]
• Provide declaration files for other ExtendScript types.

As it stands, we can get most of the way by specifying "es5". The obvious pitfall with this strategy is that some features/APIs suggested with type completion will be erroneous/not supported by the target language.

Would be nice to have an "es3" lib option...

[mhegazy]

Would be nice to have an "es3" lib option...

it sure would be. and this issue is tracking it. we would be happy to accept a PR for lib.es3.d.ts

[ericdrobinson]

Speaking for myself, I have no clue as to how the existing lib declaration files were built. Suggestions on how to quickly create a lib.es3.d.ts file (perhaps by modifying the existing es5 version?) would be instructive. Furthermore, what would you suggest to use for the target spec? This? If so, what portions are most important? I would guess that Chapter 15 - Native ECMAScript Objects would be the primary focus. Are there any other important sections? Anything important to capture in Chapter 8 - Types or Chapter 9 - Type Conversion? Or are those things handled intrinsically by TypeScript already?