Nvm-windows: 잘못된 설치 폴더

제가 잘못 알고 있는 건가요, 아니면 NVM이 400MB 노드 패키지 캐시를 내 로밍 프로필에 넣었나요?

아니요, NPM의 버그입니다.

기본 설치는 로밍이 아닌 로컬 사용자 appdata 디렉토리를 가리킵니다. 실행 파일을 다른 위치에 두는 것이 더 나을 수 있지만 모든 노드 설치 파일과 npm은 NVM용 데이터로 간주됩니다(이것은 npm 설계입니다). 다시 말하지만, 이것은 이유가 있는 기본값입니다... 마음에 들지 않으면 변경할 수 있습니다.

나는 당신이 400MB를 어디서 얻었는지 전혀 모릅니다. 환경에 대한 자세한 정보를 제공할 수 있습니까?

첫 번째 요점은 아마도 차이점은 도메인 연결 컴퓨터에 설치하고 사용자는 설치하지 않는다는 것입니다. 그러나 어느 쪽이든 그것은 여전히 ​​잘못입니다. AppData는 실행 파일이 아닌 사용자 설정을 위한 것입니다.

두 번째 요점은 노드 자체가 실수를 하는 것입니다. 별도로 버그를 신고하겠습니다.

이것이 반드시 "틀린" 것은 아니지만 부작용이 있는 경우 사용 사례를 고려하게 되어 기쁩니다. 도메인 연결 컴퓨터에 대한 동일한 경험이 없었기 때문에 환경에 대한 세부 정보가 귀하의 특정 사용 사례를 이해하는 데 도움이 될 것입니다.

예를 들어, 무엇을 찾아야 하는지 알고 있다면 설치 프로그램의 다음 버전이 도메인을 인식하도록 만들 수 있습니다. 즉, 기본 설치 위치가 더 스마트할 수 있습니다.

다음은 기본 권장 사항입니다.

• 프로그램은 %ProgramFiles% , 일반적으로 C:\Program Files 입니다.
• 64비트 머신에서 오래된 x86 프로그램은 %ProgramFiles(x86)% , 일반적으로 C:\Program Files (x86) 입니다.
• 패키지 캐시와 같은 시스템 전체의 프로그램 데이터는 %ProgramData% 로 이동합니다. 일반적으로 C:\ProgramData
• 컴퓨터에서 컴퓨터로 안전하게 로밍할 수 있는 사용자 설정은 %APPDATA% 들어갑니다.
• 주어진 시스템에 로컬인 사용자 설정(예: 설치 경로를 포함하는 설정)은 %LOCALAPPDATA% 합니다.

실행 파일이 appdata에 있는 것은 드문 일이 아닙니다. clickonce를 사용하여 설치된 응용 프로그램은 Microsoft에서 만든 설치 프로그램입니다. 크롬이 해줍니다. 많은 것들이 그렇게 합니다.

@aljones 한 가지 주요 이유는 다음과 같습니다 . 사용자 프로필에 프로그램을 설치하는 것이 편리할 수 있지만 모든 프로세스가 원하는 대로 항목을 수정할 수 있다는 점에서 보안상의 문제가 있습니다. ClickOnce는 사용자 프로필에 _설치_하지만 어셈블리가 시스템에 대해 더 적은 권한을 갖도록 합니다.

관리자 권한 없이 사용자별로 응용 프로그램을 설치하는 일반적인 사용 사례가 있지만 이는 매우 열악한 기본 동작이며 Chrome은 여기에서 나쁜 선례를 설정합니다. imho.

저는 최근의 경험이 토론과 관련이 있다고 생각합니다. 저는 최근에 워크스테이션 스위치를 사용했습니다. 내 로밍 프로필의 node_packages 경로가 너무 깊었기 때문에 내 시스템이 시도한 로밍 프로필 복원은 내가 node_packages 폴더를 제거할 때까지 매번 실패했습니다. 이러한 오류는 Windows 이벤트 로그에 나타납니다. 그렇게 한 후 내 새 워크스테이션은 마침내 내 로밍 프로필을 동기화할 수 있었습니다.

로밍에 설치하면 네트워크 내에서 사용할 프로필을 백업하는 회사에서 작업할 때 문제가 발생한다는 데 동의합니다. 예를 들어 내 컴퓨터를 종료하는 데 30분, 다시 시작하는 데 30분이 걸립니다. 모두 npm 모듈 때문입니다. 불행히도 AFAIK, 이것은 NPM 자체의 문제입니다.

이에 대한 후속 조치로:

일반적으로 모든 버전 관리자는 프로그램을 관리할 뿐입니다. 나는 이전 의견을 반복합니다.... NVM의 의미에서 설치된 프로그램(노드)은 데이터입니다. 사용 방법(예: npm 모듈)이 공간에 기여할 수 있습니다.

@sam3k 는 발자국이 npm이 어떻게 정의되었는지와 확실히 관련되어 있고 이를 위해 NVM이 _해야 하는_ 일이 많지 않으며 npm 자체가 이를 위해 할 수 있는 일도 많지 않다는 것이 맞습니다. 무엇을 설치하고 있는지 아는 것으로 귀결되며 모든 종류의 패키지 관리자를 사용하면 이를 당연하게 여깁니다. 많은 사람들은 오픈 소스 세계에 고유한 코드/환경 품질 문제인 모듈의 공간에 주의를 기울이지 않습니다. 결론적으로, 훈련된 코딩 관행(사소한 작업과는 거리가 멀음)을 통해 이 문제를 해결하는 것은 커뮤니티의 몫입니다. 저는 이것을 옹호한 많은 사람 중 한 명입니다( npm에는 개인 트레이너가 필요합니다 . 요점: npm 관리는 실행 중인 노드 버전을 관리하는 기본 전제 이상입니다.

@aljones 와 @ygra 둘 다 좋은 점이 있습니다. 나는 그들에 동의하지 않지만 모든 사람에게 심볼릭 링크가 작동하려면 관리 권한이 필요하다는 것을 상기시키고 싶습니다. 이것이 Windows용 NVM이 작동하는 방식의 핵심 원칙입니다.

@cokobware 는 엔터프라이즈 환경에서 흔히 발생하는 문제라고 생각합니다. 결론은 npm이 대규모로 쉽게 이식할 수 있도록 설계되지 않았다는 것입니다. 여러 버전을 추가하는 것은 고사하고 node+npm의 한 인스턴스는 이미 상당히 무겁습니다. 데이터/파일이 워크스테이션에서 워크스테이션으로 이동하는 방식에 관계없이 데이터/파일이 너무 많아 시간이 오래 걸립니다. 옵션은 Windows 로밍 프로필을 사용하거나 모든 항목을 압축하여 수동으로 전송하거나 npm 레지스트리에서 다시 다운로드하는 것입니다. 어떻게 돌리든 워크스테이션을 동기화하려면 모든 비트를 올바른 위치에 가져오는 데 시간이 걸립니다.

Windows용 NVM의 미래(현재)는 노드 버전 전환에 계속 초점을 맞출 것입니다. 그것을 반영하기 위해 프로젝트 이름을 변경할 수도 있습니다. 설치 프로그램에 공통 기본값을 계속 제공하지만 조직에 적합한 방식으로 이러한 기본값을 재정의하는 것은 여전히 ​​조직/개발자에게 달려 있습니다. NVM4W가 더 나은 npm 관리를 위한 후크를 제공할 수 있는 방법을 실험하고 있지만 노드 버전 관리는 npm 풋프린트 관리와 분명히 다른 문제입니다.

@Grauenwolf 제안 및 다음 참조를 따르십시오: 배포 가이드 , CSIDL 및 환경 변수

• 심볼릭 링크 %USERPROFILE%AppData를 %PROGRAMFILES% 또는 %PROGRAMFILES(X86)%에 연결하는 것은 좋지 않습니다. 다중 사용자의 문제(소유권 문제. 다른 사용자는 링크에 액세스할 수 없음).
• 프로그램 nvm은 %PROGRAMFILES% 또는 %PROGRAMFILES(X86)%에 저장되어 있다고 가정합니다.
• 범위가 모든 사용자이기 때문에 nodejses 저장소는 %PROGRAMDATA%에 저장되어야 합니다.
• 범위가 사용자 단위이므로 활성 nodejs 링크는 %LOCALAPPDATA%에 저장되어야 합니다.

다른 버그로 인해 %PROGRAMFILES%에 NVM을 설치할 수 없습니다. 이름에 공백이 있는 폴더에 넣으면 설치 명령이 실패합니다.