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: fix JSON generation for aliased methods #4871

Closed
wants to merge 1 commit into from
Closed

doc: fix JSON generation for aliased methods #4871

wants to merge 1 commit into from

Conversation

TimothyGu
Copy link
Member

For example assert/assert.ok currently has the following signature:

    "signatures": [
      {
        "params": [
          {
            "name": "value"
          },
          {
            "name": "message])"
          },
          {
            "name": "assert.ok(value"
          },
          {
            "name": "message",
            "optional": true
          }
        ]
      }
    ]

While the heading reads

assert(value[, message]), assert.ok(value[, message])

Split them into two sections to make it working.

@mscdex mscdex added doc Issues and PRs related to the documentations. assert Issues and PRs related to the assert subsystem. labels Jan 26, 2016
@evanlucas
Copy link
Contributor

/cc @nodejs/documentation

@eljefedelrodeodeljefe
Copy link
Contributor

Wouldn't it be better to fix it during JSON generation? Because the markdown renders fine and a change there doesn't seem to be something we should wish for, imo. What's your use case?

@tflanagan
Copy link
Contributor

There is precedence for this type of change:

https://nodejs.org/api/https.html#https_server_listen_handle_callback

Just a friendly reminder that the whole doc generating process is pretty fragile, so I would +1 this change, as it already exists in the HTTPS docs.

@eljefedelrodeodeljefe
Copy link
Contributor

Okay. Could we have a See assert.ok() for details. then? Because the difference is the that srv.listen() is one heading level deeper.

@TimothyGu
Copy link
Member Author

Hi,

https://nodejs.org/api/buffer.html#buffer_buf_readdoublebe_offset_noassert

is not deeper and it uses the same style.

@TimothyGu
Copy link
Member Author

Or actually it is. But I still don't see how that affects the argument.

@eljefedelrodeodeljefe
Copy link
Contributor

It's bout consistency and readability. Also prettiness and semantics, since a heading without content looks like a bug to me. Even if there were precedence.

@tflanagan
Copy link
Contributor

@eljefedelrodeodeljefe, you will find this style all over the docs. It is not a bug. It is by design.

The only argument against this is resorting the documentation which would cause duplicate documentation because we will have to move assert.ok down in the list.

As I have done this before, I am sure it is fine now.

@eljefedelrodeodeljefe
Copy link
Contributor

Then make the case. -0

@tflanagan
Copy link
Contributor

@eljefedelrodeodeljefe I would argue the case is FOR consistency and readability.

tbh, this was a mistake on my part in missing this when I reordered all the docs alphabetically, this should've already happened.

@TimothyGu
Copy link
Member Author

@tflanagan that's a good point. How about I move ok to where it should be and link assert() to assert.ok()? This way it reduces redundancy and keeps the alphabetical order.

On the doc toolchain being fragile, I totally agree.

@eljefedelrodeodeljefe there are code in the toolchain to specifically handle this sort of headings: https://github.com/nodejs/node/blob/master/tools/doc/json.js#L38-L39. So I'd argue that the headings are like this by design.

Currently assert/assert.ok currently has the following signature:

    "signatures": [
      {
        "params": [
          {
            "name": "value"
          },
          {
            "name": "message])"
          },
          {
            "name": "assert.ok(value"
          },
          {
            "name": "message",
            "optional": true
          }
        ]
      }
    ]

The heading reads

    assert(value[, message]), assert.ok(value[, message])

Split them into two sections to make it working.
@TimothyGu
Copy link
Member Author

I have just splitted the section into two, so that the alphabetical order is preserved.

@chrisdickinson
Copy link
Contributor

This LGTM. Making the headings more regular is great (even if it is to fix the JSON generator, which is pretty neglected!)

If `value` is not truthy, an `AssertionError` is thrown with a `message`
property set equal to the value of the `message` parameter. If the `message`
parameter is `undefined`, a default error message is assigned.
An alias of [`assert.ok()`][] .
Copy link
Contributor

Choose a reason for hiding this comment

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

All the other references in this document use the format assert.ok.

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

All I am saying is that, it should be consistent.

@eljefedelrodeodeljefe
Copy link
Contributor

LGTM now.

Trott pushed a commit to Trott/io.js that referenced this pull request Jan 30, 2016
Currently assert/assert.ok currently has the following signature:

    "signatures": [
      {
        "params": [
          {
            "name": "value"
          },
          {
            "name": "message])"
          },
          {
            "name": "assert.ok(value"
          },
          {
            "name": "message",
            "optional": true
          }
        ]
      }
    ]

The heading reads

    assert(value[, message]), assert.ok(value[, message])

Split them into two sections to make it working.

PR-URL: nodejs#4871
Reviewed-By: Chris Dickinson <[email protected]>
@Trott
Copy link
Member

Trott commented Jan 30, 2016

Landed in 27c8b73

@Trott Trott closed this Jan 30, 2016
@TimothyGu TimothyGu deleted the json-doc branch January 30, 2016 19:17
@jasnell
Copy link
Member

jasnell commented Feb 1, 2016

lts-watch label applied

rvagg pushed a commit that referenced this pull request Feb 8, 2016
Currently assert/assert.ok currently has the following signature:

    "signatures": [
      {
        "params": [
          {
            "name": "value"
          },
          {
            "name": "message])"
          },
          {
            "name": "assert.ok(value"
          },
          {
            "name": "message",
            "optional": true
          }
        ]
      }
    ]

The heading reads

    assert(value[, message]), assert.ok(value[, message])

Split them into two sections to make it working.

PR-URL: #4871
Reviewed-By: Chris Dickinson <[email protected]>
@MylesBorins
Copy link
Contributor

This PR will have to wait for a backlog of doc fixes to land before we can land it in LTS

@Knighton910
Copy link

👍

MylesBorins pushed a commit that referenced this pull request Feb 22, 2016
Currently assert/assert.ok currently has the following signature:

    "signatures": [
      {
        "params": [
          {
            "name": "value"
          },
          {
            "name": "message])"
          },
          {
            "name": "assert.ok(value"
          },
          {
            "name": "message",
            "optional": true
          }
        ]
      }
    ]

The heading reads

    assert(value[, message]), assert.ok(value[, message])

Split them into two sections to make it working.

PR-URL: #4871
Reviewed-By: Chris Dickinson <[email protected]>
This was referenced Jul 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assert Issues and PRs related to the assert subsystem. doc Issues and PRs related to the documentations.
Projects
None yet
Development

Successfully merging this pull request may close these issues.