You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal to transfer the Corepack repo into the Node.js organization #558
The PR at nodejs/node#35398 adds a new dependency into the Node trunk: Corepack. Since once the PR has landed the expectation is that people will only use it through Node, I believe it would make sense to move it inside the Node organization.
Maintenance:
I would be ready to keep maintaining Corepack regardless the org it belongs to, especially given the low scope (cf next section), but it would let you have a better control on what the supported workflows and integrations.
Roadmap:
Corepack is expected to stay very simple, with a low amount of features. My expectation is that it's already almost feature-complete. As a result, the roadmap will mostly be to fix launch bugs, and keep the codebase in line with the Node deprecations.
I don't like the idea of moving a TS project to the org to be added as dependency to Node.js, but we already have precedence and I think I'm somewhat alone in this position so 🤷🏻♀️
+1 to moving the repository anyway. We should have an onboarding plan to have more folks working on that project as well.
I don't like the idea of moving a TS project to the org to be added as dependency to Node.js, but we already have precedence and I think I'm somewhat alone in this position so 🤷🏻♀️
You are not alone.
Reacted by Jordan Harband, Stephen Belanger, Matteo Collina, Wes Todd, Michael Dawson, hinell and @brody2consult - Chris J. Brody
Even putting aside my apprehension of having a TS project in core, I'm not really seeing how this and the linked PR are worth the extra maintenance overhead versus just leaving it in userland. 🤔
@Qard ... I'm curious what additional overhead you're concerned about. There should be very little regular maintenance required... At least, definitely no more so than our current npm maintenance.
TS is more an abstract concern to me--mainly just that it introduces yet another thing maintainers would need to learn. However, I'm less concerned about that in this instance, I mostly just included that to share that I had similar concerns of TS in core to others whom commented here.
I'm more just questioning the value of having this particular thing in core. It's not a huge chunk of code, but it's not small either and not clear to me there's a major benefit to it being in core. It also seem a bit too magic to me, could potentially cause environment issues or user confusion.
Well, let's keep in mind that moving the repo in to the node.js org is a separate matter than deciding to ship it in core. We can decide one long before deciding the other.
@jasnell personally I would like to see the repository move to the org before landing the PR, but if I'm alone in that opinion I'm happy to drop that part of my objection there.
Also worth noting that since there are no objections here yet from TSC or CommComm (just a raised concern on TS), we can transfer the repository in 49 hours (unless we get an objection before that). So which happens first is probably moot since it's very likely that the repo will be transferred first (given the PR is not implemented as experimental at this point).
What's the concern about using typescript?
It introduces an unnecessary contribution barrier for current Node.js collaborators who are not familiar with TypeScript.
Reacted by Jordan Harband, Rick Markins and Stephen Belanger
It introduces an unnecessary contribution barrier for current Node.js collaborators who are not familiar with TypeScript.
Note that it also removes a significant part of the maintenance burden. In the end I'm fine with removing it if you feel very strongly about it, but as the one who'll keep reviewing PRs on this project, I can tell I would feel much more confident if I had a type checker running.
The question of what language is used for this should be up to the developers who are building and maintaining it and should not be a factor in deciding whether the repo can move into the organization or not.
The question of what language is used for this should be up to the developers who are building and maintaining it and should not be a factor in deciding whether the repo can move into the organization or not.
I disagree there. The maintainers are likely to change over time.
Note that I shared the project with some folks and was told that it's harder to read/follow by at least one of them for the exact reason I mentioned: TypeScript is not JavaScript. I feel strongly about it but not enough to stop progress, but the possibility of switching back to JS if TS becomes a maintenance barrier should be on the table.
Also, as the main maintainer of llnode today, we should avoid having projects in the org that are only maintained by one person, it makes everything so much harder and more fragile.
Reacted by Jan Olaf Martin, Stephen Belanger and Jordan Harband
I don't think Node should ship with any such set of basic package manager building blocks. ...
These are great points, and I think they are exactly the kind of things which should be nailed down as a part of the larger conversation. Hence my initial proposal to have a structured conversation in a smaller group with the subject matter experts like yourself. My concern is the current proposal exists, community projects exist, but Node's position is so unclear. I think a clear problem statement from the perspective of long term goals of Node would help a lot here.
Issue nodejs/node#15244 got opened three years ago ... This problem isn't new.
Totally agree. I think the challenge of an issue on the node repo is getting engagement from the right parties who are both willing to engage and also willing to help build the solution. I actively avoid those more contentious issues, and I know many other folks do the same. The cost of engagement there is just TOO DAMN HIGH. Which is why I propose a smaller group, which I have seen work.
the npm monopoly
I very much want a solution which removes this natural monopoly. I agree this is a part of the problem, but I disagree that this solution is the right one.
What it is is a problem in lack of advocated solutions.
Strong agree! I really don't like to be a dissenting voice, so I picked this issue rather carefully. An advanced solution to an unclear problem does not make sense for a project of this maturity IMO. I do think this is the wrong long term solution, but not because of poor decision making on the solution, because we do not have clarity on the problem.
(I just realized TSC and CommComm were not pinged here, so cc @nodejs/tsc @nodejs/community-committee since this is a request to transfer a repository to the org)
We may eventually get to a point where we can solve the larger problems. We may even decide that shipping corepack with the node.js binary just simply is not the right thing to do. But that is a completely separate question as to whether or not the corepack repo can move under the node.js organization. Doing so does not obligate us to any particular path moving forward and doing so helps to address one of the issues that has actually been raised in this discussion... namely, attracting additional contributors!
So, let's do this: let's separate conversation threads.
This thread is focused on whether corepack can or cannot move under the node.js organization
We can have a separate conversation about spinning up a package-manager interest group with intent of chartering a package-manager working group that can explore the longer-term concern.
The third and entirely separate conversation deals with whether we ultimately ship corepack in core by default.
Let's table 2 and 3 for now and focus on 1.
There is nothing about moving the project in to the node.js organization that obligates us to any single long-term direction.
Reacted by mary marchini, Dominykas Blyžė, Jordan Harband and Steven
Just to clarify... this issue is about adding this project under nodejs org? If so - then I think it should be done. It looks like an advanced project, that needs some incubation and experimentation, and we do have pkgjs org for just that, but at the same time - I don't think that PM WG needs to be the admin of all such incubation and experimentation projects. The whole point is that the project has maintainers and oversight (by TSC) - so what's the issue with just adding it to the org?
Whether it lands in node and is distributed together, or whether it is the right way to approach the problem, or whether using TS is a hindrance to some users are entirely different discussions, that can be had between the maintainers/TSC and whoever else needs to be involved.
Edit: I see James posted a similar thing while I was typing...
Will moving it into the node org mean others than the current IC's participate? If so, then I am on board. There are reasons I probably won't be an effective contributor (things brought up above among them) but if others will then I will withdrawal my opposition here and move it into that repo itself.
@arcanis if you want to speed up the process, here's a checklist of files you should have before moving the repository to the org:
CODE_OF_CONDUCT.md: it can be a reference to the Node.js Code of Conduct.
CONTRIBUTING.md: if there isn't one already, the contributing guide of Node.js core could be a good example. Consider including the Developer's Certificate of Origin section in the document to avoid potential copyright conflicts.
LICENSE, or other kind of documents that describe the license of the project.
README.md
I see you already have a CoC, LICENSE and README. I suggest opening a PR to add a CONTRIBUTING.md and linking the CoC to the one we use on the Node.js org. Feel free to ping me on the PR to check if everything is ok.
Also, that's not a requirement, but if you can change the default branch from master to main without breaking existing automation we recommend to do so.
I'm ok with the move of the repo, provided as @jasnell has stated that it's clear that it does not imply any agreement or consensus that it will become part of core, and it is in support of experimentation and the process of gaining consensus on next steps.
Reacted by James M Snell, Benjamin Gruenbaum, Steven, Vladimir de Turckheim, Tierney Cyren and Ruy Adorno
@mmarchini Nice! I just tried but got "You don’t have the permission to create public repositories on nodejs" - do I need to do something special on my side?
You got this error when trying to transfer the repo through settings? If that's the case give me admin permission to the repo and I'll transfer it (since I have write perm here).
Activity
mcollina commentedon Sep 28, 2020
+1
mmarchini commentedon Sep 28, 2020
I don't like the idea of moving a TS project to the org to be added as dependency to Node.js, but we already have precedence and I think I'm somewhat alone in this position so 🤷🏻♀️
+1 to moving the repository anyway. We should have an onboarding plan to have more folks working on that project as well.
cjihrig commentedon Sep 28, 2020
You are not alone.
Qard commentedon Sep 29, 2020
Even putting aside my apprehension of having a TS project in core, I'm not really seeing how this and the linked PR are worth the extra maintenance overhead versus just leaving it in userland. 🤔
jasnell commentedon Sep 29, 2020
What's the concern about using typescript?
@Qard ... I'm curious what additional overhead you're concerned about. There should be very little regular maintenance required... At least, definitely no more so than our current npm maintenance.
Qard commentedon Sep 29, 2020
TS is more an abstract concern to me--mainly just that it introduces yet another thing maintainers would need to learn. However, I'm less concerned about that in this instance, I mostly just included that to share that I had similar concerns of TS in core to others whom commented here.
I'm more just questioning the value of having this particular thing in core. It's not a huge chunk of code, but it's not small either and not clear to me there's a major benefit to it being in core. It also seem a bit too magic to me, could potentially cause environment issues or user confusion.
jasnell commentedon Sep 29, 2020
Well, let's keep in mind that moving the repo in to the node.js org is a separate matter than deciding to ship it in core. We can decide one long before deciding the other.
mmarchini commentedon Sep 29, 2020
@jasnell personally I would like to see the repository move to the org before landing the PR, but if I'm alone in that opinion I'm happy to drop that part of my objection there.
mmarchini commentedon Sep 29, 2020
Also worth noting that since there are no objections here yet from TSC or CommComm (just a raised concern on TS), we can transfer the repository in 49 hours (unless we get an objection before that). So which happens first is probably moot since it's very likely that the repo will be transferred first (given the PR is not implemented as experimental at this point).
It introduces an unnecessary contribution barrier for current Node.js collaborators who are not familiar with TypeScript.
mmarchini commentedon Sep 29, 2020
One thing we might want to consider is to also release this as
@nodejs/pmmon npm once it moves to the org, so users on LTS can try it out too.arcanis commentedon Sep 29, 2020
Note that it also removes a significant part of the maintenance burden. In the end I'm fine with removing it if you feel very strongly about it, but as the one who'll keep reviewing PRs on this project, I can tell I would feel much more confident if I had a type checker running.
jasnell commentedon Sep 29, 2020
The question of what language is used for this should be up to the developers who are building and maintaining it and should not be a factor in deciding whether the repo can move into the organization or not.
cjihrig commentedon Sep 29, 2020
I disagree there. The maintainers are likely to change over time.
mmarchini commentedon Sep 29, 2020
Note that I shared the project with some folks and was told that it's harder to read/follow by at least one of them for the exact reason I mentioned: TypeScript is not JavaScript. I feel strongly about it but not enough to stop progress, but the possibility of switching back to JS if TS becomes a maintenance barrier should be on the table.
mmarchini commentedon Sep 29, 2020
Also, as the main maintainer of llnode today, we should avoid having projects in the org that are only maintained by one person, it makes everything so much harder and more fragile.
15 remaining items
wesleytodd commentedon Sep 29, 2020
These are great points, and I think they are exactly the kind of things which should be nailed down as a part of the larger conversation. Hence my initial proposal to have a structured conversation in a smaller group with the subject matter experts like yourself. My concern is the current proposal exists, community projects exist, but Node's position is so unclear. I think a clear problem statement from the perspective of long term goals of Node would help a lot here.
Totally agree. I think the challenge of an issue on the node repo is getting engagement from the right parties who are both willing to engage and also willing to help build the solution. I actively avoid those more contentious issues, and I know many other folks do the same. The cost of engagement there is just TOO DAMN HIGH. Which is why I propose a smaller group, which I have seen work.
I very much want a solution which removes this natural monopoly. I agree this is a part of the problem, but I disagree that this solution is the right one.
Strong agree! I really don't like to be a dissenting voice, so I picked this issue rather carefully. An advanced solution to an unclear problem does not make sense for a project of this maturity IMO. I do think this is the wrong long term solution, but not because of poor decision making on the solution, because we do not have clarity on the problem.
mmarchini commentedon Sep 29, 2020
(I just realized TSC and CommComm were not pinged here, so cc @nodejs/tsc @nodejs/community-committee since this is a request to transfer a repository to the org)
jasnell commentedon Sep 29, 2020
We may eventually get to a point where we can solve the larger problems. We may even decide that shipping corepack with the node.js binary just simply is not the right thing to do. But that is a completely separate question as to whether or not the corepack repo can move under the node.js organization. Doing so does not obligate us to any particular path moving forward and doing so helps to address one of the issues that has actually been raised in this discussion... namely, attracting additional contributors!
So, let's do this: let's separate conversation threads.
This thread is focused on whether corepack can or cannot move under the node.js organization
We can have a separate conversation about spinning up a package-manager interest group with intent of chartering a package-manager working group that can explore the longer-term concern.
The third and entirely separate conversation deals with whether we ultimately ship corepack in core by default.
Let's table 2 and 3 for now and focus on 1.
There is nothing about moving the project in to the node.js organization that obligates us to any single long-term direction.
dominykas commentedon Sep 29, 2020
Just to clarify... this issue is about adding this project under nodejs org? If so - then I think it should be done. It looks like an advanced project, that needs some incubation and experimentation, and we do have pkgjs org for just that, but at the same time - I don't think that PM WG needs to be the admin of all such incubation and experimentation projects. The whole point is that the project has maintainers and oversight (by TSC) - so what's the issue with just adding it to the org?
Whether it lands in node and is distributed together, or whether it is the right way to approach the problem, or whether using TS is a hindrance to some users are entirely different discussions, that can be had between the maintainers/TSC and whoever else needs to be involved.
Edit: I see James posted a similar thing while I was typing...
wesleytodd commentedon Sep 29, 2020
👍
Will moving it into the node org mean others than the current IC's participate? If so, then I am on board. There are reasons I probably won't be an effective contributor (things brought up above among them) but if others will then I will withdrawal my opposition here and move it into that repo itself.
mmarchini commentedon Sep 29, 2020
@arcanis if you want to speed up the process, here's a checklist of files you should have before moving the repository to the org:
I see you already have a CoC, LICENSE and README. I suggest opening a PR to add a CONTRIBUTING.md and linking the CoC to the one we use on the Node.js org. Feel free to ping me on the PR to check if everything is ok.
Also, that's not a requirement, but if you can change the default branch from
mastertomainwithout breaking existing automation we recommend to do so.mhdawson commentedon Sep 30, 2020
I'm ok with the move of the repo, provided as @jasnell has stated that it's clear that it does not imply any agreement or consensus that it will become part of core, and it is in support of experimentation and the process of gaining consensus on next steps.
mmarchini commentedon Oct 8, 2020
@arcanis per our process this is now approved, you can transfer the repository to the
nodejs/org.arcanis commentedon Oct 8, 2020
@mmarchini Nice! I just tried but got "You don’t have the permission to create public repositories on nodejs" - do I need to do something special on my side?
mmarchini commentedon Oct 8, 2020
You got this error when trying to transfer the repo through settings? If that's the case give me admin permission to the repo and I'll transfer it (since I have write perm here).
arcanis commentedon Oct 8, 2020
I transferred it to your account, so you should be able to re-transfer it to @nodejs 😄
mmarchini commentedon Oct 8, 2020
lol
mmarchini commentedon Oct 8, 2020
done https://github.com/nodejs/corepack