-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create ES3 specific lib.d.ts #2410
Comments
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. |
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 This misstake causes that if I use a non-defined 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 I think I can't explain it better... :S |
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. |
Would probably accept a PR on a good es3.lib.d.ts |
This is very interesting at Enterprise environments that works with legacy browsers. |
related to #6974 |
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:
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:
As it stands, we can get most of the way by specifying Would be nice to have an |
it sure would be. and this issue is tracking it. we would be happy to accept a PR for lib.es3.d.ts |
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? |
I would start by lib.es5.d.ts, and go through he spec remove/update declarations as necessary. |
5.1 |
@mhegazy Is there a resource that describes how the lib files are structured and why they are structured in the manner that they are? For example, why are all built-in types declared as This seems to make some kind of sense for One drawback(?) that I'm seeing with the interface method being employed is that [when using JavaScript, at least] the global namespace is filled not with classes as one might expect, but interfaces. I understand that JavaScript classes are not "real" classes, per se, but it is also somewhat surprising to see autocomplete turn up Basically, why this: // Instance-side.
interface Blah {
num: number;
}
// Static-side.
interface BlahConstructor {
val: object;
new (): Blah;
}
declare const Blah: BlahConstructor; instead of this: declare class Blah {
constructor();
static val: object;
num: number;
} Convention? Or some deeper reason...? (Please let me know if there is a better place to ask such questions. I ask them here to help anyone else considering taking on the task of creating the "es5" lib who may also not be terribly familiar with "why" behind the architecture.) |
classes are not callable. most of the built-in objects e.g. |
that is unfortunate, and we tried to limit it to only required objects, e.g. DOM APIs do not behave the same way. One thing to note, you need to keep the structure, for things like |
On Callable Core "classes"
Ahh, so that is what the last two lines of this are then: interface ObjectConstructor {
new (value?: any): Object;
(): any;
(value: any): any;
//...
} I'd actually not previously understood why those were there. Makes much more sense. Improvements to Callable
|
I'll answer my own question here. Yes: it appears that this is by design. For anyone interested in more, this blog entry is extremely helpful. The main documentation is also helpful if you look for "call signature" (under Function Types) and "construct signature" (under Difference between the static and instance sides of classes). |
sure. it just that ppl do not use |
yes. these are not meant to be implemented, but rather to describe JS objects that do exist. |
@mhegazy I bet. Doesn't mean that it isn't technically wrong ;) |
it is not wrong. it is just not that common. |
Reopened my PR as #28372, if anyone still is interested. |
Comments in the linked PR |
By targeting to ES3, the following code (within a class definition):
compiles, but the
item
variable is not defined. Does reallyitem
exists in a ES3 standard browser? I wasn't able to find it, so I treated this as a bug.The text was updated successfully, but these errors were encountered: