Node.js Foundation Technical Steering Committee (TSC) Meeting 2019-07-17 #732

Activity

1. mhdawson

   self-assigned this

   on Jul 15, 2019
2. Trott commented on Jul 15, 2019

   

   Trott

   on Jul 15, 2019

   Last edited by Trott

   Member

   More actions

   Based on nodejs/Release#341 (comment), should nodejs/Release#341 be removed from the agenda? If so, then we have a very light agenda, with the only non-standing issue being something that has an active email thread going on. Seems like the meeting could be canceled.
3. mhdawson commented on Jul 15, 2019

   

   mhdawson

   on Jul 15, 2019

   MemberAuthor

   More actions

   Yes, #341 should have had the tag removed, done that now and removed from agenda.
4. mhdawson commented on Jul 15, 2019

   

   mhdawson

   on Jul 15, 2019

   MemberAuthor

   More actions

   I'm +1 to canceling this week unless somebody has something to add to the agenda.
5. clarkbw commented on Jul 16, 2019

   

   clarkbw

   on Jul 16, 2019

   More actions

   👋I'd like to join this meeting and discuss some package namespace concepts the GitHub Package Registry team is considering. We would value your input on the direction we're taking.

   Single source of truth

   For simplicity and security GPR (the GitHub Package Registry) plans to provide a system for "upstreaming NPM" such that our users only need to add a single registry URL to their config.

   npm login --registry=https://npm.pkg.github.com

   Through this single URL users should have access to both NPM packages and those packages which reside on GPR. However we have been running into issues with namespace conflicts with the NPM registry given its global name resolution and separate namespace system.

   Namespace Problems

   GitHub offers namespaces through organizations (https://github.com/nodejs/), users (https://github.com/clarkbw), and repos (https://github.com/nodejs/TSC/ or https://github.com/clarkbw/jest-localstorage-mock). But our namespaces are often different from those namespaces on NPM and this creates the conflict when trying to use a single source; who is correct if both have an answer.

   For example our system currently allows you to require a module with a namespace. Without upstream support this isn't a problem but when we combine both our system and NPM you don't know which system namespace @octo-org should resolve to.

     "dependencies": {
       "@octo-org/octo-app": "1.0.0"
     }

   This namespace conflict is apparent with namespaces google-cloud and GoogleCloudPlatform where the URLs are https://www.npmjs.com/org/google-cloud and https://github.com/GoogleCloudPlatform respectively. If a user specified @GoogleCloudPlatform and that was also registered on NPM it would be unclear what the user wanted and vice versa for @google-cloud and that namespace being on GitHub.

   URLs as namespace

   Our long term plan is to use URLs as a namespace prefix such that @octo-org/octo-app should actually be written as github.com/octo-org/octo-app. We believe this makes namespace resolution obvious and in control of the developers while also securing users from squatting attacks and being more future proof.

   The problem we face when trying to use URLs is that the NPM client mostly assumes that a GitHub URL means direct git access to the repository as seen in the NPM docs. An npm install github.com/octo-org/octo-app or npm install https://github.com/octo-org/octo-app either fails or connects to the git server.

   Protocol as namespace

   An alternate version of the URL as namespace is using a protocol instead such that GPR requests are prefixed with github:. An npm install github:octo-org/octo-app isn't ideal like URLs are but would work if the NPM client didn't already use the github: protocol for direct git server access.

   Hybrid solution

   The GPR team would like to make progress on the longer term solution, we believe to be something like URL namespaces. At the same time we want to make forward progress on a solution that could work better in the next couple months.

   We're looking at a number of different solutions for the near term that will allow our users to use GPR as expected while we work toward a more stable namespace solution like URLs. These solutions are purely temporary so we can get up and running without requiring changes to clients that take time to propagate out.

   Namespace Prefix

   One example temporary solution is to use a prefix on namespace like @gh- so users would enter @google-cloud/storage for the default NPM namespace and @gh-GoogleCloudPlatform/storage for the GitHub namespace. We are not in 😍with this.

   ---

   We're humbled to be able to take part in this conversation and appreciate your time, thoughts, and advice on these proposals.

   👍React with 👍4Reacted by Ian Sutherland, Benjamin Gruenbaum, Liran Tal and Spiral2k

   👀React with 👀1Reacted by Darcy Clarke
6. ljharb commented on Jul 16, 2019

   

   ljharb

   on Jul 16, 2019

   SponsorMember

   More actions

   cc @nodejs/modules

   @clarkbw we have a meeting of the Modules group tomorrow (nodejs/modules#349 (comment)); it might be a better place to have initial conversations?
7. clarkbw commented on Jul 16, 2019

   

   clarkbw

   on Jul 16, 2019

   More actions

   @clarkbw we have a meeting of the Modules group tomorrow (nodejs/modules#349 (comment)); it might be a better place to have initial conversations?

   Happy to join that one instead and not be on the hook for an 8am meeting 😴 😄

   😄React with 😄1Reacted by Jordan Harband
8. hybrist commented on Jul 16, 2019

   

   hybrist

   on Jul 16, 2019

   More actions

   @clarkbw It may help to copy that write-up into an issue (either in nodejs/node or nodejs/modules) so we can properly tag it and also in case there's additional discussion beforehand.

   👍React with 👍1Reacted by Bryan Clark
9. mhdawson commented on Jul 16, 2019

   

   mhdawson

   on Jul 16, 2019

   MemberAuthor

   More actions

   @clarkbw I was just coming back to this issue to see if we'd cancel for this week. If a good starting point is to start the discussion in the modules team meeting then I'll go ahead and cancel this unless there are objections from @nodejs/tsc

   👍React with 👍2Reacted by Rich Trott and Bryan Clark
10. clarkbw commented on Jul 16, 2019

    

    clarkbw

    on Jul 16, 2019

    More actions

    @clarkbw I was just coming back to this issue to see if we'd cancel for this week. If a good starting point is to start the discussion in the modules team meeting

    I'm happy to start there!

    ❤️React with ❤️1Reacted by Jordan Harband
11. mhdawson commented on Jul 17, 2019

    

    mhdawson

    on Jul 17, 2019

    MemberAuthor

    More actions

    Canceling meeting for today. If you are interested in the discussion on namespacing make sure to attend the Modules meeting today.
12. mhdawson

    closed this as completedon Jul 17, 2019