Skip to content

Conversation

@andersk
Copy link

@andersk andersk commented Oct 27, 2025

This will help prevent regressions similar to #6033 in the future.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
@changeset-bot
Copy link

changeset-bot bot commented Oct 27, 2025

⚠️ No Changeset found

Latest commit: ce9334e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Member

@Murderlon Murderlon left a comment

Choose a reason for hiding this comment

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

I think I'm against this change, it's very verbose for no benefit at all. We have to put up with this in our entire codebase while there is only benefit for the user facing types, not all the code within.

Copy link
Contributor

@mifi mifi left a comment

Choose a reason for hiding this comment

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

exactOptionalPropertyTypes is now recommended by typescript so I agree it makes sense to enable it.

Also, I see that we don't currently have any large pending PRs that would cause a merge conflict with this, so I think it's ok to make the change now.

See my comments about adding null values and simplifying the explicit undefined checks

const body = opts.formData
? this.createFormDataUpload(file, opts)
: file.data
: (file.data ?? null)
Copy link
Contributor

Choose a reason for hiding this comment

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

this seems unrelated?

file: UppyFile<M, B>,
chunk: Chunk,
signal?: AbortSignal,
signal: AbortSignal | null = null,
Copy link
Contributor

Choose a reason for hiding this comment

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

I see that you add null as an option many places. why not undefined? null seems more like an explicit value to me, rather than an absent one.

getChunkSize: this.opts.getChunkSize
? this.opts.getChunkSize.bind(this)
: undefined,
...(this.opts.getChunkSize !== undefined && {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think in the cases where the optional value is an object or a function, we can simplify these, so it doesn't looks so long and ugly:

Suggested change
...(this.opts.getChunkSize !== undefined && {
...(this.opts.getChunkSize && {

} else if (this.#isRestoring) {
this.options.companionComm.restoreUploadFile(this.#file, {
uploadId: this.options.uploadId,
...(this.options.uploadId !== undefined && {
Copy link
Contributor

Choose a reason for hiding this comment

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

here i agree we should use the !== undefined check because the string could be '' which we probably want to include

companionHeaders: this.opts.companionHeaders,
companionKeysParams: this.opts.companionKeysParams,
companionCookiesRule: this.opts.companionCookiesRule,
...(this.opts.companionHeaders !== undefined && {
Copy link
Contributor

Choose a reason for hiding this comment

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

for example these we could also simplify

Suggested change
...(this.opts.companionHeaders !== undefined && {
...(this.opts.companionHeaders && {

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants