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

Remove assumption regarding local git clone #209

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

aduh95
Copy link
Contributor

@aduh95 aduh95 commented Mar 14, 2025

IMO it's bad practice to assume the doc will be in a git directory, and to assume it would have an origin remote pointing to HTTPS or SSH GitHub repo. It would be much better to let the user opt-in into that behavior, and default to an hard-coded value.

Description

Validation

Related Issues

Check List

  • I have read the Contributing Guidelines and made commit messages that follow the guideline.
  • I've covered new added functionality with unit tests if necessary.

@aduh95 aduh95 requested a review from a team as a code owner March 14, 2025 16:45
@@ -2,10 +2,6 @@

import { basename, dirname, join } from 'node:path';
import { writeFile } from 'node:fs/promises';
import {
Copy link
Member

Choose a reason for hiding this comment

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

Can you delete these utils if they're not used anywhere else?


const tag = getCurrentGitHash(repositoryDirectory);
const tag = 'HEAD';
Copy link
Member

Choose a reason for hiding this comment

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

Is it fine for us to assume HEAD?

Copy link
Member

Choose a reason for hiding this comment

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

In dev it shouldn't really matter, but for releases it needs to be a hash since the line numbers referenced are going to change eventually.

I.e. for the latest v20 release, https://github.com/nodejs/node/blob/bb1a61d8737feff534bb85368dab3b7c554c863d/lib/_http_client.js#L869 is correct vs https://github.com/nodejs/node/blob/HEAD/lib/_http_client.js#L869 points to something else.

@flakey5
Copy link
Member

flakey5 commented Mar 15, 2025

Fwiw the current behavior is almost directly taken from the old doc tooling https://github.com/nodejs/node/blob/63e3cc7e82a645b0763174f306bfe589164ce7d6/tools/doc/apilinks.mjs#L38-L45

Copy link
Member

@flakey5 flakey5 left a comment

Choose a reason for hiding this comment

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

It would be much better to let the user opt-in into that behavior

How will a user be able to opt-in?

@aduh95
Copy link
Contributor Author

aduh95 commented Mar 15, 2025

It would be much better to let the user opt-in into that behavior

How will a user be able to opt-in?

There are numerous possibilities (env variables, CLI flag, some config file). Anyway, my point is that it’s better IMO to

  1. Have it opt-in, rather than
  2. not have it at all, rather than
  3. Have is opt-out, rather than
  4. Have it without any way for disabling it

Currently, this PR is not implementing the best solution, but I still think it’s an improvement

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.

4 participants