[DOCS] Clarification on the proper way to change settings when doing a fork

[sneko]

Is there an existing issue for this?

• I have searched the existing issues

This is a CLI Docs Enhancement, not another kind of Docs Enhancement.

• This is a CLI Docs Enhancement.

Description of Problem

Hi,

I posted today semantic-release/npm#483 but I think at the end it's more appropriate to ask the question here since it's a general question:

I'm in a situation where I want to fork a repository to do a pull request and I know the PR won't be accepted within a few weeks/months. So I want to be able to use the package properly but also to let others too.

My idea is to fork the repository, try to setup the needed workflows of this repo (CircleCI in this case, but also CodeClimate...). Let's say I set up all the tools so I don't have to modify workflows files.

Now since the package is named abc and the name is already taken on the npmjs.com repository I have to use a scope like @sneko/abc. But my question is:

What's the best way to adjust settings to only reroute publishing the package to my own scope?

Because I could modify in package.json all the properties: .name, .author, .repository.url but I feel it not appropriate since my fork is not intended to replace the original one (it's just temporary).

I read some discussions on this repo and it seems I could try to play with the setting .publishConfig or try to use a file .npmrc but in all cases, it makes me adding a new commit to do so, so my pull-request to the original repo will have this content, no?

What's the best way to make this transparent? An environment variable into my CI/CD workflow so npm publishes into the right scope? (if so, can someone tell me which one and what to set into?)

Thank you,

(sorry if I missed the information somewhere)

Potential Solution

I don't know what is the solution.

But I would love to be able to manage through an environment variable the "package name" to say: it's not abc but it's @sneko/abc.

:)

Docs URL

No response

[ljharb]

This feels more like community norms than CLI documentation.

I’d say that it’d be enough to change the name to a scoped one, and add a line to the readme saying it’s a temporary fork and linking to the PR(s), and then you can npm deprecate it once the PRs are merged and released.

[sneko]

@ljharb correct me if I'm wrong but:

If I start a PR to the original repository with the improvements, and then I commit adjustments to publish the package on my own (adding the scope, modifying the README.md...) it will adjust/affect the PR directly (with those latter modifications). Am I right?

If so, the solution would be (naming as example ^^):

• use a branch improvement (to commit the improvements of the library)
• create a branch publish where I push modifications about the scope and the README.md modification
• I do the PR to the original repo from the branch improvement
• to release on my own scope, I just merge improvement into publish

I'm not against this if that's the most appropriate way to do it. Just thought maybe a simpler way would exist: to override the scope when publishing through environment variable.

(I understand your point about the "community norm", but if there is a possibility to override the scope when publishing I would expect it to be in the documentation)

[ljharb]

Yes, that’s basically right - the branch you work on and publish wouldn’t be the same one you made the PR from.

I’m not aware of any way to override the package name when publishing; it has to be actually in the package.json.

[sneko]

Thank you @ljharb for the information that confirms using 2 branches with PRs :)

I will leave the issue open so maybe more people can see it and share their thoughts. Because my original need of modifying dynamically the final package name does not seem to me like something counterproductive. (but indeed if I'm the only one requesting it, that's probably the wrong way ^^)