├── GOVERNANCE.md ├── LICENSE.md ├── README.md ├── edge_cases.md ├── initial_proposal.md └── meetings ├── 2016-11-15.MD └── 2016-12-01.md /GOVERNANCE.md: -------------------------------------------------------------------------------- 1 | ### Version Management Discussion Group 2 | 3 | The Node.js Version Management Discussion Group is currently a temporary group 4 | created to facilitate discussion amongst stakeholders about version managers 5 | for Node and their potential place in the core project. 6 | 7 | This group has final authority over this discussion and planning including: 8 | 9 | * Technical direction 10 | * Project governance and process (including this policy) 11 | * Contribution policy 12 | * GitHub repository hosting 13 | * Conduct guidelines 14 | * Maintaining the list of group collaborators 15 | 16 | For the current list of members, see the project [README.md](./README.md#current-project-team-members). 17 | 18 | ### Collaborators 19 | 20 | The Version Management GitHub repository is maintained by this group 21 | and additional Collaborators who are added. 22 | 23 | Individuals making significant and valuable contributions are made 24 | Collaborators and given commit-access to the project. These 25 | individuals are identified by the WG and their addition as 26 | Collaborators is discussed during the weekly WG meeting. 27 | 28 | _Note:_ If you make a significant contribution and are not considered 29 | for commit-access log an issue or contact a WG member directly and it 30 | will be brought up in the next WG meeting. 31 | 32 | Modifications of the contents of the Version Management repository are made on 33 | a collaborative basis. Anybody with a GitHub account may propose a 34 | modification via pull request and it will be considered by the project 35 | Collaborators. All pull requests must be reviewed and accepted by a 36 | Collaborator with sufficient expertise who is able to take full 37 | responsibility for the change. In the case of pull requests proposed 38 | by an existing Collaborator, an additional Collaborator is required 39 | for sign-off. Consensus should be sought if additional Collaborators 40 | participate and there is disagreement around a particular 41 | modification. See _Consensus Seeking Process_ below for further detail 42 | on the consensus model used for governance. 43 | 44 | Collaborators may opt to elevate significant or controversial 45 | modifications, or modifications that have not found consensus to the 46 | WG for discussion by assigning the ***WG-agenda*** tag to a pull 47 | request or issue. The WG should serve as the final arbiter where 48 | required. 49 | 50 | For the current list of Collaborators, see the project 51 | [README.md](./README.md#current-project-team-members). 52 | 53 | ### Consensus Seeking Process 54 | 55 | This group follows a [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) 56 | decision-making model. 57 | 58 | When an agenda item has appeared to reach a consensus the moderator 59 | will ask "Does anyone object?" as a final call for dissent from the 60 | consensus. 61 | 62 | If an agenda item cannot reach a consensus a group member can call for 63 | either a closing vote or a vote to table the issue to the next 64 | meeting. The call for a vote must be seconded by a majority of the WG 65 | or else the discussion will continue. Simple majority wins. 66 | 67 | 68 | ## Developer's Certificate of Origin 1.1 69 | 70 | By making a contribution to this project, I certify that: 71 | 72 | * (a) The contribution was created in whole or in part by me and I 73 | have the right to submit it under the open source license 74 | indicated in the file; or 75 | 76 | * (b) The contribution is based upon previous work that, to the best 77 | of my knowledge, is covered under an appropriate open source 78 | license and I have the right under that license to submit that 79 | work with modifications, whether created in whole or in part 80 | by me, under the same open source license (unless I am 81 | permitted to submit under a different license), as indicated 82 | in the file; or 83 | 84 | * (c) The contribution was provided directly to me by some other 85 | person who certified (a), (b) or (c) and I have not modified 86 | it. 87 | 88 | * (d) I understand and agree that this project and the contribution 89 | are public and that a record of the contribution (including all 90 | personal information I submit with it, including my sign-off) is 91 | maintained indefinitely and may be redistributed consistent with 92 | this project or the open source license(s) involved. 93 | 94 | ### Moderation Policy 95 | 96 | The [Node.js Moderation Policy][] applies to this group. 97 | 98 | ### Code of Conduct 99 | 100 | The [Node.js Code of Conduct][] applies to this group. 101 | 102 | [Node.js Code of Conduct]: https://github.com/nodejs/node/blob/master/CODE_OF_CONDUCT.md 103 | [Node.js Moderation Policy]: https://github.com/nodejs/TSC/blob/master/Moderation-Policy.md 104 | 105 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2016 Node.js Contributors 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy of 6 | this software and associated documentation files (the "Software"), to deal in 7 | the Software without restriction, including without limitation the rights to 8 | use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of 9 | the Software, and to permit persons to whom the Software is furnished to do so, 10 | subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS 17 | FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR 18 | COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER 19 | IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN 20 | CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE 21 | 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## Node.js Version Management Discussion Group 2 | 3 | This repo and discussion group is to facilitate collaboration amongst 4 | maintainers and stakeholders for Node version and runtime configuration managers. 5 | Its purpose is to arrive at recommendations and a roadmap for version 6 | management under the auspices of Node.js core and the Node.js Foundation, per 7 | request of the Node.js TSC in its Nov-3-2016 meeting. 8 | 9 | The TSC has asked for these at their next meeting, Nov-17-2016. 10 | 11 | [Initial Proposal](./initial_proposal.md) provides an initial description of 12 | the benefits improved version management will bring to Node's users and why 13 | this would be most successful if closely aligned with the runtime itself 14 | here in the Node Foundation. 15 | 16 | ## Current Project Team Members 17 | 18 | * @ljharb 19 | * @jasongin 20 | * @coreybutler 21 | * @tjwebb 22 | * @marcelklehr 23 | * @joshgav 24 | * @refack 25 | * @shadowspawn 26 | * @jasonkarns 27 | -------------------------------------------------------------------------------- /edge_cases.md: -------------------------------------------------------------------------------- 1 | #Use Cases 2 | 3 | If you created or are maintaining a version manager, please help identify edge/use cases you've encountered. 4 | 5 | ## Redeployment 6 | (by @coreybutler) 7 | 8 | In some environments (government, defense, some corporations), the developer environment is locked down. 9 | To facilitate this, many organizations utilize Active Directory as a source of supervised software installations. 10 | 11 | - Difficult/impossible to track usage. 12 | - Silent installers are necessary (must be modifiable by the organization) 13 | - Alternative feed of version availability is necessary to prevent confusion. 14 | 15 | ## Offline Access Use Case 16 | (by @coreybutler) 17 | 18 | A state education agency managed technical infrastructure for all school districts, many of which are in rural/remote areas. 19 | Some of them have no internet access, and many have very strained bandwidth, yet they want/need to use newer versions of Node. 20 | They need a local mirror of Node executables, as well as npm mirrors (optional, but mostly impractical to not have this). 21 | 22 | - Difficult/impossible to track usage. 23 | - Completely different update method (manually copy resources to a mirror from a USB drive or other physically transportable media) 24 | - A feed of available versions needs to be accessible in a LAN. 25 | 26 | ## Roaming Profiles & npm Bloat 27 | (by @coreybutler) 28 | 29 | A company uses roaming profiles, expecting their node environments to roam with them. Global `node_modules` are a part of this. 30 | Due to the number of dependencies, the `node_modules` directory was enormous, and “almost redundant”, meaning many versions of 31 | the same module with minor variations. This caused the user a 30 minute bootup time while waiting for ALL node environments to copy 32 | from the server to a new desktop. 33 | 34 | - Horrible user experience 35 | 36 | ## Architecture Awareness 37 | (by @coreybutler) 38 | 39 | Some native dependencies require different versions of libraries depending on the architecture (32 vs 64 bit). Users need a 40 | `node_modules` directory specific to a version of node and it’s architecture. 41 | 42 | - 2 global node_modules directories per Node.js version if supporting both 32/64-bit (double the already large footprint). 43 | 44 | ## Yarn: Missing Information 45 | (by @coreybutler) 46 | 47 | When yarn was released, it was looking for a specific Windows registry key to determine whether Node was installed on the 48 | system. Different version managers approach the registry differently. Since there is no spec answering “how to determine 49 | if Node is installed?”, version managers have provided alternative solutions. 50 | 51 | - Lacking an “authoritative” spec stifles integration. 52 | 53 | ## Confused Community 54 | (by @coreybutler) 55 | 56 | Many people do not understand the differences between version managers. The yarn team [didn’t realize](https://github.com/yarnpkg/yarn/issues/626#issuecomment-252993114) 57 | people were using certain version managers at all. At NINA'16, @williamkapke mentioned that he just assumed nvm and n were the same thing. 58 | Many people confuse nvm and nvm-windows as being the same functional thing for different operating systems. 59 | 60 | - Insufficient and/or unclear public messaging. 61 | 62 | _NOTE:_ @marcelklehr put together a concise [list of usage types](https://github.com/nodejs/version-management/issues/4#issuecomment-258567834) that would 63 | make a good starting point to educate the community about the options (or at least make them aware they have a choice). 64 | 65 | ## Permission Problems (Shims) 66 | (by @coreybutler) 67 | 68 | Using a shim changes the execution context of the node process (I troubleshoot this all the time in [node-windows](https://github.com/coreybutler/node-windows)). 69 | A shim may run under a specific user (root, elevated admin), but it treats node as a child process, which (unless specified) runs 70 | under the default user context. In other words, it masks the user context. 71 | 72 | - Symlinks execute node “directly”, guaranteeing the user context. 73 | - Shims can potentially change the value of `__dirname, process.cwd()`, and user. 74 | - Symlinks on Windows can be hard or soft. This choice effects whether it will work across multiple hard drives on a computer. 75 | -------------------------------------------------------------------------------- /initial_proposal.md: -------------------------------------------------------------------------------- 1 | ## Why should version management be in core? 2 | 3 | Environment managers like Python's [venv][]/virtualenv, Ruby's [rvm][], and 4 | Node's [nvm][] make it easy for users to install and configure a runtime's 5 | versions and constituent components. Each virtual environment can support a 6 | specific runtime version and configuration and an independent set of global 7 | modules. In fact, some runtimes, such as [.NET Core][], can bundle and refer to 8 | a specific runtime configuration for each app. To summarize, environment 9 | managers enable developers to: 10 | 11 | * install the runtime with a specific configuration. 12 | * change runtime configurations for test and other needs. 13 | * manage runtime and component updates. 14 | 15 | [venv]: https://docs.python.org/3/library/venv.html 16 | [rvm]: https://rvm.io/ 17 | [nvm]: https://github.com/creationix/nvm 18 | [.NET Core]: https://docs.microsoft.com/en-us/dotnet/articles/core/deploying/index#self-contained-deployments-scd 19 | 20 | The usefulness of and demand for environment managers for Node.js is clear from the 21 | many managers already available today, including: 22 | 23 | * [nvm](https://github.com/creationix/nvm) 24 | * [nave](https://github.com/isaacs/nave) 25 | * [nodist](https://github.com/marcelklehr/nodist) 26 | * [n](https://github.com/tj/n) 27 | * [nvm-windows](https://github.com/coreybutler/nvm-windows) 28 | * [nvs](https://github.com/jasongin/nvs) 29 | * [installer](https://github.com/nodejs/installer) 30 | 31 | A full list including different capabilities and semantics is 32 | [here](https://cdn.rawgit.com/jasongin/cf9f64dd2739d78412bb9410701bf166/raw/69d48e0774f43280763eb7bb7175e930ab3e9f33/NodeVersionManagers.html) 33 | - props to [@jasongin](https://github.com/jasongin). 34 | 35 | The number of configuration options, operating environments and major 36 | version releases for Node.js continues to multiply and yet there is no official 37 | way to use multiple of these versions at the same time. 38 | 39 | Even though there are version managers available, each of them tackles only some of 40 | these options, and only in certain environments. For example, some work on 41 | Windows, some only on Linux. Some use shell script, some use JavaScript, and 42 | some use Go. Some support different environments per directory/project, and some 43 | only support an environment per shell or user. It would be simpler for 44 | developers to have at least one manager which supported all of Node.js's 45 | supported platforms and potential configurations. 46 | 47 | In addition, how runtime configuration is specified and implemented requires 48 | close collaboration and feedback between those responsible for the runtime 49 | itself and those responsible for its manager. For example, if a developer wants 50 | to utilize LibreSSL instead of OpenSSL within an app or module, the runtime 51 | itself must accomodate this and provide a way for runtime managers to determine 52 | and set that configuration. Similarly, if developers want ways to specify 53 | alternate JS runtimes, the runtime itself must support this and provide an 54 | external configuration mechanism. It would be easiest for the runtime and its 55 | manager(s) to be developed in close collaboration. 56 | 57 | Finally, while having many unofficial tools and options arguably provides 58 | greater flexibility, it also places a significant burden on downstream 59 | developers, who must choose and learn different tools and their semantics for 60 | different use cases. For example, a developer wanting to test an app on Windows 61 | and Linux must use a different env manager for each. If they encounter trouble, 62 | they must determine whether this particular manager modifies the PATH variable, 63 | symlinks into existing directories, or some other mechanism. Developers would be 64 | well served by at least one environment manager which works and behaves the same 65 | way everywhere. 66 | 67 | To achieve the above goals of: 68 | 69 | a) a manager which supports all of Node's supported platforms and configurations; 70 | b) close collaboration between runtime and runtime manager development; and 71 | c) better useability for downstream developers, 72 | 73 | we should bring together maintainers of these disparate projects and try to build 74 | at least one official Node environment manager with the best ideas and 75 | implementations from each project. 76 | 77 | To achieve this, let's designate a repo as a workspace and create an informal or 78 | formal working group to pursue the goals described above. Let's invite 79 | maintainers and stakeholders from existing projects and Node.js core to initial 80 | discussions and meetings and therein agree on goals and roadmap. And then let's 81 | collaborate to refine the result and add more options based on our users' needs. 82 | 83 | -------------------------------------------------------------------------------- /meetings/2016-11-15.MD: -------------------------------------------------------------------------------- 1 | 2 | ## Attendees 3 | 4 | - Jordan Harband @ljharb 5 | - William Kapke @williamkapke 6 | - Myles Borins @TheAlphaNerd 7 | - Jeremiah Senkpiel @Fishrock123 8 | - Corey Butler @coreybutler 9 | - Chris Brody @brodybits 10 | - Marcel Klehr @marcelklehr 11 | - George Adams @georgeadams95 12 | - Jason Ginchereau @jasongin 13 | 14 | ## Audio 15 | 16 | 17 | ## Notes 18 | 19 | Jordan started by talking about adoption of nvm into Node foundation as being separate from the longer-term WG goal. 20 | 21 | - Myles, while supportive, was trying to better understand Jordan's reasons. Jordan's answers included: governance 22 | (so the project's survival doesn't rely on a single maintainer), licensing support, testing infrastructure. 23 | - Jeremiah relayed the TSC's conerns about a project joining the foundation only to stagnate/die. Jordan suggested 24 | it would still be better for a project (particularly one having a lot of users/infrastructure depending on it) 25 | to stagnate while under the foundation rather than not under it, and also suggested the foundation membership 26 | didn't have to be permanent: a project could be deprecated or removed after it was replaced by something newer. 27 | - Others were still concerned about the adoption leading to the perception of nvm being promoted as the "standard", 28 | even if that was explicitly not the intention. 29 | 30 | Corey and Myles suggested the WG should develop "standards" for all version management tools so they work in a consistent way. 31 | 32 | - (Think of the Promises/A+ spec that many JS promise libraries converged on.) 33 | - Marcel asked whether there's any benefit to having multiple tools if they are all implementing the same standard. 34 | - Jason pointed out standards would have to be limited in scope to avoid dictating specific switching mechanisms and thus 35 | excluding many tools. 36 | - Jordan thought that the standards could leave room for different tools to be better adapted to different platforms or 37 | scenarios. 38 | - There was some concern that standards (or version-switching in general) could not be implemented consistently across 39 | platforms, for example symlinks; Jason pointed out that is largely disproven by nvs. 40 | 41 | Jerimiah is interested in a GUI installer using a version manager or potentially selecting from multiple version managers. 42 | 43 | - It could replace the existing Windows (MSI) and Mac installers which are difficult to maintain. 44 | 45 | George and Chris promoted nvs as a potential solution/inspiration for a converged tool. 46 | 47 | - Jordan agreed nvs is closest being the best long-term design approach. 48 | - Jordan was concerned nvs's approach isn't suitable for some corner cases (and maybe no single tool could cover all of them). 49 | -------------------------------------------------------------------------------- /meetings/2016-12-01.md: -------------------------------------------------------------------------------- 1 | ## Version Management and Installers Discussion 2 | 3 | * Date: 2016-12-01 (Collaboration Summit - Austin) 4 | * GitHub issue: 5 | * Minutes: 6 | 7 | ## Attendees 8 | 9 | * Corey Butler (@coreybutler) 10 | * Myles Borins (@thealphanerd) 11 | * Josh Gavant (@joshgav) 12 | * William Kapke (@williamkapke) 13 | * Mikeal Rogers (@mikeal) 14 | * Jeremiah Senkpiel (@fishrock123) 15 | * Troy Connor (@troy0820) 16 | 17 | **Next steps:** 18 | 19 | * Document and come to consensus on default patterns, paths, etc. 20 | * Investigate cross-platform installer options like Electron. 21 | * Track usage of different installation methods on website, perhaps via a 22 | header. 23 | * Add a guide to the web site on available version managers and how they work. 24 | 25 | --- 26 | 27 | What are the use cases for version managers? 28 | 29 | * Developer installing on a local machine, we don’t want to force them to the 30 | command line. 31 | * Developer who needs to switch environments for testing. 32 | * Assist with updates to runtime. 33 | 34 | Installation is our most important use case, enable people to get started 35 | quickly from the web site home page. 36 | 37 | Some systems have their own system package manager (apt, homebrew). But the 38 | package author would bypass any of our systems and use the raw tarballs. 39 | 40 | Should we orient around the needs of the installer? What might that mean? 41 | 42 | * Would be best if the installer utilized the command-line/API packages. 43 | * Consider Electron installer? 44 | * Initial download is 136MB, but may be possible to trim. 45 | * Work has begun at [nodejs/installer](https://github.com/nodejs/installer). 46 | * Are there alternatives? 47 | * bitRock 48 | * Qt? 49 | * Web page with config options which generates a script which can be run 50 | automatically. 51 | 52 | Should we focus on a JS implementation? 53 | 54 | * Would encourage more contributors, but is that important? 55 | * nvm uses POSIX. Best part is that it doesn’t require JS or a Node runtime. But 56 | it doesn’t work on Win32 and it’s more difficult to modify. 57 | * Maybe we should focus on Windows independently anyway? JS code would also be 58 | full of “#ifdef”-like statements. 59 | 60 | What about nvm being in the Foundation? 61 | 62 | * Should only projects actively supported by core be in Foundation? 63 | * Bring them all in? Not sustainable. 64 | * So if something is to be in core/Foundation, would need to be one, and would 65 | need to follow documented patterns and standards. 66 | * Should it be nvm? Maybe, still too early to tell. First come to consensus on 67 | standard patterns. 68 | 69 | Why did we choose to do certain things in existing installers? E.g. 70 | /usr/local/bin on Linux, /Users/ on Windows. Perhaps ask @bnoordhius. 71 | 72 | --------------------------------------------------------------------------------