Skip to content
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

fix(dts): add missing types to support resizable arraybuffer #54637

Conversation

indrajitbnikam
Copy link

Fixes #54636

I am opening this PR to fix the missing(not updated) type for ArrayBuffer. This PR is being raised due to this discussion in denoland/deno issue here.

@typescript-bot typescript-bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Jun 13, 2023
src/lib/es5.d.ts Outdated Show resolved Hide resolved
@indrajitbnikam
Copy link
Author

@microsoft-github-policy-service agree

@indrajitbnikam
Copy link
Author

Also, Can you help me understand how to fix this test case? https://github.com/microsoft/TypeScript/actions/runs/5258441307/jobs/9502673967?pr=54637#step:5:137

Copy link
Contributor

@Josh-Cena Josh-Cena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. You should be adding this to esnext.d.ts, not es5.
  2. You need to do the same for SharedArrayBuffer.

@fatcerberus
Copy link

You should be adding this to esnext.d.ts, not es5.

Now that you mention it, why is ArrayBuffer defined in es5 instead of es2015?

@indrajitbnikam
Copy link
Author

indrajitbnikam commented Jun 14, 2023

What exactly do you want me to add to esnext.d.ts? All the ArrayBuffer-related types?

It is just referencing other libs at the moment.
image

Most of the types lie in es5.d.ts.

Also, SharedArrayBuffer is located in es2017.sharedmemory.d.ts. Are any changes required for SharedArrayBuffer such as where should it be?

@Josh-Cena
Copy link
Contributor

Josh-Cena commented Jun 14, 2023

why is ArrayBuffer defined in es5 instead of es2015?

Because... ArrayBuffer is es5? For example it was first in Chrome v7, far before es6.

What exactly do you want me to add to esnext.d.ts?

If you use lib: "es2017" then you will be forbidden to use anything later than that. This is the way TS ensures you don't use things your runtime doesn't support. You would add the resizing-related APIs to esnext, and then declaration merging will make both the base types and the new APIs available for lib: "esnext" users. For example, you can take a look at how the array methods are split across almost every ES version.

@fatcerberus
Copy link

fatcerberus commented Jun 14, 2023

Because... ArrayBuffer is es5?

It’s not. It’s not mentioned anywhere in the ES5.1 spec AFAICT and I specifically remember it not being supported in many ES5 engines such as Duktape until it got standardized with ES6, which was a pain point for me at the time.

@Josh-Cena
Copy link
Contributor

Mmm, you are right—it's implemented around 2010, which is after ES5 already. Still it does seem older than most ES6 APIs (Promise, Map, Symbol, etc.)

@petamoriken
Copy link
Contributor

@indrajitbnikam TypeScript's interface can be typedefs as patches from a separate d.ts file.

How about the following:

  1. Create a new esnext.arraybuffer.d.ts file and write interface for ResizableArrayBuffer and GrowableSharedArrayBuffer
  2. Add /// <reference lib="esnext.arraybuffer" /> to esnext.d.ts

@petamoriken
Copy link
Contributor

It’s not. It’s not mentioned anywhere in the ES5.1 spec AFAICT and I specifically remember it not being supported in many ES5 engines such as Duktape until it got standardized with ES6, which was a pain point for me at the time.

Historically ArrayBuffer was defined by Khronos for WebGL and then moved to ES2015. That's why ArrayBuffer can be used in IE11, which should only be implemented up to ES5.1. It is odd that it defined in es5.d.ts, but it is useful for web developers.

@indrajitbnikam
Copy link
Author

indrajitbnikam commented Jun 14, 2023

I've made the changes locally but for some reason, Git is ignoring the newly added esnext.arraybuffer.d.ts file so can't push it. Can somebody help me understand why it is like this?

image
image

@indrajitbnikam
Copy link
Author

indrajitbnikam commented Jun 14, 2023

Also, I was checking what all changes are there for other such files. I added these entries based on what I found. Let me know if I'm doing something wrong.

image

image

@jakebailey
Copy link
Member

Adding an entirely new lib.d.ts file requires updating a few things, including src/lib/libs.json and libEntries in src/compiler/commandLineParser.ts.

@indrajitbnikam
Copy link
Author

Hi @jakebailey I've changed these files as you can see in my comment above.

@jakebailey
Copy link
Member

Ah, sorry, missed the second message.

The errors in the editor are necessarily provided by the version of TypeScript provided by VS Code or in node_modules, so you're going to get that message unless you change VS Code to a local build (or this change is released).

As for the git problem, it's likely that I broke something in .gitignore when I removed the top level lib dir. Let me go check.

@jakebailey
Copy link
Member

Yep, my bad. Sent #54644.

@jakebailey
Copy link
Member

For now, you can manually git add it by force.

@indrajitbnikam
Copy link
Author

Thanks for clarifying so quickly 😊

@indrajitbnikam indrajitbnikam force-pushed the fix/dts-update-type-for-arraybuffer branch 2 times, most recently from b0f736a to 5925906 Compare June 14, 2023 17:17
@indrajitbnikam indrajitbnikam force-pushed the fix/dts-update-type-for-arraybuffer branch from 5925906 to e675236 Compare June 14, 2023 17:18
@indrajitbnikam
Copy link
Author

indrajitbnikam commented Jun 14, 2023

Also, I have another question about these already existing types,

Have a look at this slice() method signature.

Existing code

slice(begin: number, end?: number): SharedArrayBuffer;

MDN Doc (here)

image

How to cover this scenario?

@indrajitbnikam
Copy link
Author

indrajitbnikam commented Jun 14, 2023

Should I do it the way I've done it over here for all missing constructor signatures for SharedArrayBuffer?

image

Frankly speaking, I think this can be fixed with a single type as follows.

interface SharedArrayBufferConstructor {
  new(byteLength?: number, options?: SharedArrayBufferOptions): SharedArrayBuffer
}

What do you think?

@petamoriken
Copy link
Contributor

petamoriken commented Jun 15, 2023

Since ES2017, not only TypedArray but also ArrayBuffer and DataView constructors are allowed to be empty.

tc39/ecma262#410

So to modify es2017.sharedmemory.d.ts and to add new es2017.arraybuffer.d.ts and es2017.dataview.d.ts are make sense for me.

@petamoriken
Copy link
Contributor

petamoriken commented Jun 17, 2023

@indrajitbnikam

Do you want me to do that change or we are just discussing it?

This is just my opinion, I think there needs to be a decision by TypeScript members.

Also, I'm not sure how to fix the failing tests. Can you help me understand it?

The baseline test seems to be failed.

Baselines are used to manage if there are any changes in the expected output of the TypeScript compiler. Baselines are located in tests/baselines.

  1. Run the tests: hereby runtests-parallel
  2. Check baseline changes: git diff --diff-filter=AM --no-index ./tests/baselines/reference ./tests/baselines/local
  3. Accept baseline changes: hereby baseline-accept

Please see https://github.com/microsoft/TypeScript/blob/main/CONTRIBUTING.md#managing-the-baselines

@typescript-bot typescript-bot added For Backlog Bug PRs that fix a backlog bug and removed For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Jun 17, 2023
@indrajitbnikam
Copy link
Author

Hi @petamoriken,

This is just my opinion, I think there needs to be a decision by TypeScript members.

Ohh, I get it.

By the way, Thanks a lot for helping me understand why tests were failing. I had missed reading that section of CONTRIBUTING.md file. I would have never realized the issue, at least not this fast.

@indrajitbnikam
Copy link
Author

Hi @petamoriken

Can you help me understand what should be described here in this related issue for this PR?
image

Should it be ESnext as we are adding our patch to the esnext files?

@petamoriken
Copy link
Contributor

Should it be ESnext as we are adding our patch to the esnext files?

Yes, that's right.

@indrajitbnikam
Copy link
Author

Hi @fatcerberus @Josh-Cena @jakebailey , Can someone check the PR and let me know if I need to change something?

Copy link
Contributor

@Josh-Cena Josh-Cena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly LGTM, with a note that the TS repo usually uses 4 spaces for indentation. But you really don't have to ping me for reviews; you can simply ask the team (which is i.e. Jake in the current thread :))

/**
* Read-only. The maximum length that this ArrayBuffer can be resized to (in bytes).
*/
readonly maxByteLength: number;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest using get maxByteLength(): number unless the team thinks otherwise; ditto for the other occurences.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've seen the readonly as well in multiple places. But yeah, let's wait for the team to comment on it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @Josh-Cena, the spec example uses accessors, so it makes sense to do so here.

(It's quite likely that old readonlys should be changed to accessors, but that might break backward compatibility, eg classes extend lib interfaces and override properties.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @Josh-Cena, the spec example uses accessors, so it makes sense to do so here.

(It's quite likely that old readonlys should be changed to accessors, but that might break backward compatibility, eg classes extend lib interfaces and override properties.)

That seems like a breaking change we might want to take, though perhaps only if we can find a way to only enable it when --useDefineForClassProperties is true or the target it sufficiently high enough to warrant it.

@indrajitbnikam
Copy link
Author

Mostly LGTM, with a note that the TS repo usually uses 4 spaces for indentation. But you really don't have to ping me for reviews; you can simply ask the team (which is i.e. Jake in the current thread :))

Oh Sorry, did not realise that. Thanks for reviewing though 😊.

@sandersn sandersn requested review from sandersn and removed request for fatcerberus June 28, 2023 21:40
Copy link
Member

@sandersn sandersn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs a test in tests/cases/conformance/esnext that shows off example uses of the new entries. The file should be named esnextArrayBuffer.ts or similar, and the first line should be

// @lib: esnext.arraybuffer

so that the test harness will use the right lib setting

@@ -216,6 +216,7 @@ const libEntries: [string, string][] = [
["esnext.array", "lib.es2023.array.d.ts"],
["esnext.collection", "lib.es2023.collection.d.ts"],
["esnext.symbol", "lib.es2019.symbol.d.ts"],
["esnext.arraybuffer", "lib.esnext.arraybuffer.d.ts"],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rbuckton Do you have an opinion abut we should add a separate lib entry for arraybuffer? This feels like the kind of thing that went in to earlier es20xx.collection entries.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resizable ArrayBuffers and growable SharedArrayBuffers are Stage 4 and will be in ES2024 when it is standardized, so a lib.es2024.arraybuffer.d.ts might make sense at this point, though it would still only be referenced from esnext since we don't have a --target es2024 yet..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or a lib.es2024.collections.d.ts, rather. I agree it makes more sense to try to keep the names somewhat consistent.

/**
* Read-only. The maximum length that this ArrayBuffer can be resized to (in bytes).
*/
readonly maxByteLength: number;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @Josh-Cena, the spec example uses accessors, so it makes sense to do so here.

(It's quite likely that old readonlys should be changed to accessors, but that might break backward compatibility, eg classes extend lib interfaces and override properties.)


interface SharedArrayBuffer {
/**
* Read-only. Whether this SharedArrayBuffer can be grow or not.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Read-only. Whether this SharedArrayBuffer can be grow or not.
* Returns true if this SharedArrayBuffer can grow.

Although, growable is self-explanatory, and the current explanation is redundant with it. If we must have a jsdoc here, I'd prefer to see an explanation of context or what different properties a growable SharedArrayBuffer has, or a link to an explanation.

}

/**
* ArrayBuffer constructor options
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would delete this. It doesn't add anything to the name of the type.

readonly maxByteLength: number;

/**
* Read-only. Whether this ArrayBuffer can be resized or not.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* Read-only. Whether this ArrayBuffer can be resized or not.
* Returns true if this ArrayBuffer can be resized.

Actually, my comments about growable apply; I'd prefer to delete this comment.

* Resizes the ArrayBuffer to the specified size (in bytes).
* @param newLength The new length, in bytes, to resize the ArrayBuffer to.
*/
resize(newLength: number): undefined;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would call this newByteLength like the proposal does. Then consider deleting the jsdoc.

@@ -0,0 +1,58 @@
interface ArrayBuffer {
/**
* Read-only. The maximum length that this ArrayBuffer can be resized to (in bytes).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spec proposal points out that this is equal to byteLength if options.maxByteLength is not provided. I'd stay closer to the example's explanation:

Suggested change
* Read-only. The maximum length that this ArrayBuffer can be resized to (in bytes).
* If this ArrayBuffer is resizable, returns the maximum byte length given during construction; returns the byte length if not.

@sandersn sandersn self-assigned this Jun 29, 2023
@lino-levan
Copy link

@indrajitbnikam are you willing to push this forward? If not, I'd be willing to take this on.

@seirdotexe
Copy link

Any updates? Node 20 LTS is coming soon, so would be nice if the types are there, too 😊

@domoritz
Copy link

@indrajitbnikam are you still working on this? This is currently blocking me from cleanly adopting reusable buffers.

@indrajitbnikam
Copy link
Author

indrajitbnikam commented Dec 17, 2023 via email

@domoritz
Copy link

Okay. Unfortunately, I don't have cycles to fix this right now. I hacked around the types in apache/arrow#39252 for now.

@sandersn
Copy link
Member

To help with PR housekeeping, I'm going to close this PR since it is stale and there's an updated version at #57858.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
For Backlog Bug PRs that fix a backlog bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fix(dts): Update type of ArrayBuffer