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

doc: documentation of sync methods links now to async methods #21243

Closed
wants to merge 7 commits into from

Conversation

iwko
Copy link
Contributor

@iwko iwko commented Jun 10, 2018

Documentation of sync methods links now to async methods if it made sense

Checklist

Refs: #21197

@nodejs-github-bot nodejs-github-bot added doc Issues and PRs related to the documentations. fs Issues and PRs related to the fs subsystem / file system. labels Jun 10, 2018
Copy link
Contributor

@vsemozhetbyt vsemozhetbyt left a comment

Choose a reason for hiding this comment

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

Thank you! There are some nits we need to fix)

doc/api/fs.md Outdated
@@ -1826,6 +1830,8 @@ added: v0.8.6

Synchronous ftruncate(2). Returns `undefined`.

For detailed information, see the documentation of [`fs.ftruncate()`][].

This comment was marked as resolved.

doc/api/fs.md Outdated
@@ -2867,6 +2883,8 @@ changes:

Synchronous symlink(2). Returns `undefined`.

For detailed information, see the documentation of [`fs.symlink()`][].

This comment was marked as resolved.

doc/api/fs.md Outdated
@@ -1143,6 +1143,8 @@ changes:
Synchronously changes the permissions of a file. Returns `undefined`.
This is the synchronous version of [`fs.chmod()`][].

For detailed information, see the documentation of [`fs.chmod()`][].
Copy link
Member

Choose a reason for hiding this comment

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

This seems unnecessary given the immediately previous sentence.

doc/api/fs.md Outdated
@@ -1573,6 +1575,8 @@ changes:
Synchronous version of [`fs.exists()`][].
Returns `true` if the path exists, `false` otherwise.

For detailed information, see the documentation of [`fs.exists()`][].
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 greatly prefer we stick with the wording used elsewhere:

This is the synchronous version of [`fs.exists()`][].

Trott
Trott previously requested changes Jun 10, 2018
Copy link
Member

@Trott Trott left a comment

Choose a reason for hiding this comment

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

Many of these contain links we should definitely add while many others of these changes also seem to add unnecessary sentences, as they often repeat the information in the sentence that comes right before them.

@Trott
Copy link
Member

Trott commented Jun 10, 2018

Hi, @iwko! Welcome, and thanks for the pull request! Documentation changes can often attract a lot of review comments. I hope you'll be patient and not be discouraged. Thanks!

@vsemozhetbyt
Copy link
Contributor

cc @joyeecheung to chime in.

@joyeecheung
Copy link
Member

joyeecheung commented Jun 10, 2018

@Trott See #21197 and #21193

Also I was confused when I got started with fs documentation as well. There are no clear indications that you should click the link to find out more information e.g. about what the arguments actually mean. Just listing arguments without any explanation following by Synchronous version of <a link> is not enough IMO, people would just think that the documentation of the async API would not be informative either if they don't get curious and actually click the link.

Maybe a better way to fix this would be instead of saying Synchronous version of <a link>, say

For detailed information, see the documentation of the asynchronous
version of this API: <a link>

But I guess the point of saying Synchronous version of is to make sure people are aware that the async version is preferred?

@Trott
Copy link
Member

Trott commented Jun 10, 2018

For detailed information, see the documentation of the asynchronous version of this API:

@joyeecheung Something like that would make sense to me. But given what you wrote, I guess the current version of this is still an improvement. I'll remove my request for changes. This can always be iterated on going forward.

@nodejs/documentation

@Trott Trott dismissed their stale review June 10, 2018 21:18

reconsidering

@iwko
Copy link
Contributor Author

iwko commented Jun 11, 2018

So, should I change my changes to For detailed information, see the documentation of the asynchronous version of this API: <a link>?

@vsemozhetbyt
Copy link
Contributor

@joyeecheung
Copy link
Member

So, should I change my changes to For detailed information, see the documentation of the asynchronous version of this API: ?

I would say yes, but let's see what other people from @nodejs/fs @nodejs/documentation think. With that style we will lose the emphasis on making the async versions the perferred APIs.

@vsemozhetbyt
Copy link
Contributor

How should we proceed?

@Trott
Copy link
Member

Trott commented Jun 18, 2018

I hate to do this but this is more than a week old and has attracted very little attention from @nodejs/documentation so I'm going to do the dreaded @nodejs/collaborators...

@targos
Copy link
Member

targos commented Jun 18, 2018

The text LGTM as is

@davisjam
Copy link
Contributor

@iwko Thank you for this PR! Here are some comments.

  1. I share @Trott's concerns about repetition. While it's true that "This is the synchronous version of X" doesn't necessarily indicate that X has more complete documentation, I'm not sure that presenting this in separate sentences like "This is the synchronous version of X. See X for the full API." is the right approach.

We could prefix this document with "The asynchronous version of APIs documents parameters. The synchronous version indicates only the return value and exceptional behavior.". That would only help someone who bothers to read the complete document though.

I would prefer merging the two into a single sentence as @Trott proposed: "For detailed information, see the documentation of the asynchronous version of this API: a link". I don't think we need to explicitly mention everywhere that you should use asynchronous APIs. That's more the job of guides like this one. I don't think API docs need to take as firm a stance on this, especially not on a per-API basis.

  1. fs is not the only module with synchronous and asynchronous versions. For example, the crypto module has synchronous and asynchronous versions of pbkdf2. The approach to documenting the sync vs. async versions seems inconsistent between fs and crypto. Should this PR attempt to achieve uniformity across all such modules?

@joyeecheung
Copy link
Member

@davisjam I agree that merging the sentences would more better, but we can probably leave the crypto docs for another PR.

@iwko Can you update the PR according to the suggestions above? Thanks!

@iwko
Copy link
Contributor Author

iwko commented Jun 23, 2018

@joyeecheung Sure thing

@iwko
Copy link
Contributor Author

iwko commented Jun 23, 2018

@joyeecheung done

@vsemozhetbyt
Copy link
Contributor

doc/api/fs.md Outdated
@@ -1143,6 +1143,9 @@ changes:
Synchronously changes the permissions of a file. Returns `undefined`.
This is the synchronous version of [`fs.chmod()`][].
Copy link
Member

Choose a reason for hiding this comment

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

@iwko I believe @davisjam and @Trott and I meant that sentence like

 This is the synchronous version of [`fs.chmod()`][].

Should be removed after sentences like

For detailed information, see the documentation of the asynchronous version of
this API: [`fs.chmod()`][].

are added to avoid duplication?

Copy link
Contributor Author

@iwko iwko Jun 25, 2018

Choose a reason for hiding this comment

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

I am a little confused now. So documentation for fs.chmod() should look like this?

Synchronously changes the permissions of a file. Returns undefined. For detailed information, see the documentation of the asynchronous version of this API: [fs.chmod()][]. See also: chmod(2).
?

Copy link
Member

Choose a reason for hiding this comment

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

@iwko Yes, that's my understanding

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@iwko
Copy link
Contributor Author

iwko commented Jun 29, 2018

I've done all changes. What do You think? @vsemozhetbyt @Trott @davisjam @joyeecheung

@joyeecheung joyeecheung added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Jun 29, 2018
@davisjam
Copy link
Contributor

@iwko I will have time to look today or tomorrow.

doc/api/fs.md Outdated
@@ -1140,8 +1140,10 @@ changes:
* `path` {string|Buffer|URL}
* `mode` {integer}

Synchronously changes the permissions of a file. Returns `undefined`.
This is the synchronous version of [`fs.chmod()`][].
Returns `undefined`.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it worth to completely skip these notes? We usually do not state anything if a function returns undefined.

doc/api/fs.md Outdated
@@ -4589,6 +4621,7 @@ the file contents.
[`fs.chown()`]: #fs_fs_chown_path_uid_gid_callback
[`fs.copyFile()`]: #fs_fs_copyfile_src_dest_flags_callback
[`fs.exists()`]: fs.html#fs_fs_exists_path_callback
[`fs.ftruncate()`]: #fs_fs_ftruncate_fd_len_callback
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: this one should go after the next reference, ABC-wise.

Copy link
Contributor

@davisjam davisjam left a comment

Choose a reason for hiding this comment

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

LGTM, thank you!

@iwko
Copy link
Contributor Author

iwko commented Jul 8, 2018

When this PR will be merged?

@Trott
Copy link
Member

Trott commented Jul 8, 2018

When this PR will be merged?

@iwko Can you address the two nits from @vsemozhetbyt? Specifically, there's no need to indicate that undefined is returned by a function, and there's one reference that is out of alphabetical order.

Once that's done, we can run CI and probably land this promptly. (There may be an issue with the merge commit recently added to the branch. Our CI setup does not like merge commits, or at least didn't used to. But we'll deal with that when we get there.)

@iwko
Copy link
Contributor Author

iwko commented Jul 8, 2018

@Trott I've made changes

@vsemozhetbyt
Copy link
Contributor

@Trott Trott force-pushed the fs-doc-sync-methods branch from 038be2d to 9921a76 Compare July 9, 2018 04:26
@Trott
Copy link
Member

Trott commented Jul 9, 2018

Looks like CI failed because of the merge commit. I've squashed out the merge commit.

CI: https://ci.nodejs.org/job/node-test-pull-request-lite/906/

Would probably be good for people who have approved this to look it over again and make sure they still approve. I don't expect anyone to rescind their approval but this has nonetheless gone through substantial evolution.

@iwko
Copy link
Contributor Author

iwko commented Jul 9, 2018

@vsemozhetbyt @joyeecheung @davisjam @TimothyGu @jasnell

Are you still ok with those changes?

@vsemozhetbyt
Copy link
Contributor

Still LGTM)

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

LGTM

Trott pushed a commit to Trott/io.js that referenced this pull request Jul 9, 2018
Add links to async methods and make wording consistent.

PR-URL: nodejs#21243
Refs: nodejs#21197
Reviewed-By: Tiancheng "Timothy" Gu <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Vse Mozhet Byt <[email protected]>
Reviewed-By: Jamie Davis <[email protected]>
Reviewed-By: Matteo Collina <[email protected]>
@Trott
Copy link
Member

Trott commented Jul 9, 2018

Landed in 65208d0.

Thanks for the contribution! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. doc Issues and PRs related to the documentations. fs Issues and PRs related to the fs subsystem / file system.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants