Skip to content

Conversation

Lord-Kamina
Copy link

Removed most if not all unnecessary promises from the FS api. Note, this was tested by running the app on a new profile but my setup isn't giving me any real errors for some reason, so check and/or correct accordingly.

@CLAassistant
Copy link

CLAassistant commented Aug 26, 2025

CLA assistant check
All committers have signed the CLA.

Copy link
Owner

@ebkr ebkr left a comment

Choose a reason for hiding this comment

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

I've added a couple of comments but it has a bunch of IDE errors so I'll stop reviewing for now.

This is what it looks like in WebStorm (partly due to .catch(return false)):

image image

You'd need to change the type definitions in NodeFsProvider however I don't entirely agree with the type definition changes.

The reason we say we're returning Promise<X> on all of these is because that's quite literally the return type. An async method will always return a Promise regardless and it's somewhat misleading IMO to say that our method isn't returning the same as what it actually is. This is a snippet from MDN to make it a bit clearer:

image

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function#description.

Basically async x(...): string is always converted implicitly to async x(...): Promise<string> and so we might as well make it clear. Specifying that return type doesn't cause the method to return Promise<Promise<string>>

Comment on lines 11 to 16
async exists(path: string): boolean {
await NodeFs.lock.acquire(path, async () => {
const result = await fs.promises.access(path, fs.constants.F_OK).catch(return false);
return true;
}).catch(return false);
}
Copy link
Owner

Choose a reason for hiding this comment

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

  1. You can't have return false as a value inside a catch block. A method invocation is required. This would mean it becomes: .catch(() => false) in both cases
  2. Is the second catch block necessary? Why can we not just:
Suggested change
async exists(path: string): boolean {
await NodeFs.lock.acquire(path, async () => {
const result = await fs.promises.access(path, fs.constants.F_OK).catch(return false);
return true;
}).catch(return false);
}
await NodeFs.lock.acquire(path, async () => {
return await fs.promises.access(path, fs.constants.F_OK).catch(() => false);
});

Copy link
Author

Choose a reason for hiding this comment

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

Hadn't seen these comments. I'll fix them when I've got a minute.

Although, maybe in the long run it'd be better to rethrow/convert to your custom error class?

}
async mkdirs(path: string): void {
await NodeFs.lock.acquire(path, async () => {
await fs.promises.mkdir(path, { recursive: true }).catch (e) {
Copy link
Owner

Choose a reason for hiding this comment

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

.catch( ... throw) does the exact same thing as not having a catch block in the first place. You don't need the catch block.

@Lord-Kamina Lord-Kamina force-pushed the quasar-kill-promises branch 4 times, most recently from 56c13d3 to 558a346 Compare August 27, 2025 22:13
@Lord-Kamina Lord-Kamina force-pushed the quasar-kill-promises branch from 32873cc to 5f770df Compare August 29, 2025 12:55
@Lord-Kamina Lord-Kamina requested a review from ebkr August 29, 2025 12:55
ebkr and others added 7 commits September 9, 2025 15:58
Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
On macOS, running via `npm run` makes `moveToNextScreen` go down the linux instead of the darwin branch, which eventually leads to `getLaunchArgs is not a function` error.

Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
@Lord-Kamina Lord-Kamina force-pushed the quasar-kill-promises branch 2 times, most recently from fd05d48 to 5cf8d7f Compare September 10, 2025 15:26
Weird, I was sure I had fixed them before.

Signed-off-by: Gregorio Litenstein <g.litenstein@gmail.com>
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