teambit / bvm Goto Github PK

Creating a ~/bin folder in the user's home directory is a bit imposing, especially without a . prefix so it's not hidden on most OSes; supporting an alternative install path for the linked binary other than ~/bin/bit (for example, co-locating it in ~/.bvm) would be appreciated/ reasonable.

I'd personally like to suggest just putting it in ~/.bvm/bit (since the folder is already there) and updating the documentation accordingly. $PATH has to be updated already for the current install directory scheme, so this change doesn't seem to be particularly disruptive.

it's possible to change the name of the bit command, for example:

bvm config set DEFAULT_LINK bbiitt
bvm link
# command bbiitt is now available

after which, there is not way to remove the old command.
it should be as simple as

rm `which $OLD_COMMAND_NAME`

additionally, we should prompt the user with a hint to remove the old link, like

❯ bvm config set DEFAULT_LINK bbiitt
❯ bvm install
# ...
❯ bvm config set DEFAULT_LINK bit
❯ bvm link
name bit points to version 0.0.406
successfully linked binaries
use `bvm unlink bbiitt` to remove old command
# or
rm `which bbiitt` to remove old command

When upgrading, we show the version of the newly installed package:

harmony-base-ui git/master*  
❯ bvm upgrade
✔ extracting /Users/kutner/.bvm/temp/0.0.324 in 1 minute, 26.699 seconds
✔ removing /Users/kutner/.bvm/temp/0.0.324 in 30 milliseconds
✔ moving from temp folder to final location in 4 milliseconds
current is now linked to version 0.0.324 in path /Users/kutner/.bvm/versions/0.0.324

can you add currently installed version to the output?
e.g.:

harmony-base-ui git/master*  
❯ bvm upgrade
i current version: 0.0.322 in path /Users/kutner/.bvm/versions/0.0.322
✔ extracting /Users/kutner/.bvm/temp/0.0.324 in 1 minute, 26.699 seconds
✔ removing /Users/kutner/.bvm/temp/0.0.324 in 30 milliseconds
✔ moving from temp folder to final location in 4 milliseconds
current is now linked to version 0.0.324 in path /Users/kutner/.bvm/versions/0.0.324

Generally, we should always reflect the state to the user.

❯ bit crunch cheeriOS
i Going to crunch "cheeriOS"!
i Cereals package is half full, and after crunch it will be quarter full.
....
✔ Cereals crunched!
✔ Bowl cleaned!
i A quarter of the box is left

Hi, I have faced this problem often on my system, the installation of the bit command is too slow, sometimes it took 20 minutes and others it just stuck and never ends and sometimes it just take hours to finish, in this example I'm trying to install it on a Docker container under node v16.

For testing I just created a Dockerfile, run it and then attach a shell for running the bvm install command manually.

FROM node:16-bullseye

RUN npm i -g @teambit/bvm

# RUN bvm install

ENTRYPOINT ["tail", "-f", "/dev/null"]

Is there a way to get the Bit executable manually? I just want it for my Dev Container in VSCode but this is a blocker, imagine running a dev container that tooks hours for start the first time.

Seems like only the latest 20 versions are available to install. This is currently breaking our CI since we can't upgrade to > 0.0.653 due to compile errors and the one we had it fixed to (0.0.651) is no longer available to install.

You can replicate it even if you run bvm list --remote, you'll only get the latest 20. I think this intended since you can use --limit=XXX to see older versions but seems like the default limit of 20 is also limiting the list of versions available to install to only the latest 20.

Did a quick research and the problem seems to be that slice method's limit arg has a default value of 20
https://github.com/teambit/bvm/blob/main/teambit.bvm/list/version-list/remote-version-list.ts#L15

but the limit is never changed when fetching, so only fetches the latest 20 versions
https://github.com/teambit/bvm/blob/main/teambit.bvm/fetch/fetch.ts#L32

So maybe removing the limit/slicing and passing the 20 default limit when running list could be a better approach

I could create a PR for this but I'm not sure how to test bvm locally. If you could guide me or point me to any guide on how to do it I can do it myself, otherwise let me know if you guys need any extra info from me.

I have installed npx @teambit/bvm install. After that I want to check bvm and bit. bit working, and bvm throws an error

bvm : The term 'bvm' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a
path was included, verify that the path is correct and try again.
At line:1 char:1
bvm -v

bvm -v print 0.0.30

nothing print while running bvm install, terminal hang

All published npm packages from this repo are currently missing LICENSE information. This means certain organizations cannot use bvm because they cannot verify that the license permits their usage.

The following packages are missing license info:

• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• @teambit/[email protected]
• [email protected] (perhaps out-of-scope for this issue?)
• @teambit/[email protected]

Hey guys, I wanted to install Bit harmony, so I followed the Docs, installed BVM, and, well, tried to install Bit, here is the result:

$ bvm install
Cannot read property 'map' of undefined
TypeError: Cannot read property 'map' of undefined 
at GcpList.<anonymous> (C:\Users\tarasenko_ag\AppData\Roaming\npm\node_modules\@teambit\bvm\node_modules\@teambit\bvm.list\dist\gcp\gcp-list.js:27:42)     
    at Generator.next (<anonymous>)
    at fulfilled (C:\Users\tarasenko_ag\AppData\Roaming\npm\node_modules\@teambit\bvm\node_modules\@teambit\bvm.list\dist\gcp\gcp-list.js:5:58)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

Cannot really say much about that since I barely started...
bvm - 0.0.30
node - 16.2.0
npm - 7.13.0

After downloading, extraction takes a long while (~1 minute?)
It needs to show progress

Hello! You should never suggest the user to use setx command on Windows like in this warning:

global Bit install location was not found in your PATH global variable.
please run the following command and then re-open the terminal:
setx path "%path%;C:\Users\Komputer\AppData\Local\.bvm" and re-open your terminal
for more information read here - https://harmony-docs.bit.dev/introduction/installation

setx is potentially dangerous because it has 1024 character limit. If you exceed this limit, then the PATH variable will be truncated to 1024 chars which will break the user's machine.
You can read more about this issue here:
https://superuser.com/questions/812754/how-to-recover-from-path-being-truncated-to-1024-characters-by-setx
https://superuser.com/questions/387619/overcoming-the-1024-character-limit-with-setx
https://stackoverflow.com/a/37304698

reproduce

bvm config set RELEASE_TYPE stable
bvm install <nightly version number>

error

Cannot read properties of undefined (reading 'filter')
TypeError: Cannot read properties of undefined (reading 'filter')
    at GcpList.<anonymous> (/Users/gilad/.nvm/versions/node/v16.20.0/lib/node_modules/@teambit/bvm/node_modules/@teambit/bvm.list/dist/gcp/gcp-list.js:60:51)
    at Generator.next (<anonymous>)
    at fulfilled (/Users/gilad/.nvm/versions/node/v16.20.0/lib/node_modules/@teambit/bvm/node_modules/@teambit/bvm.list/dist/gcp/gcp-list.js:5:58)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

I'm trying to follow the quickstart for next.js (https://bit.dev/docs/quick-start/hello-world-nextjs) by executing the following command:

bit new hello-world-nextjs bit-hello-world-nextjs --env teambit.community/starters/hello-world-nextjs

but it returns the following error:

Node version 21.1.0 is not supported, please use Node.js >=16.0.0 <21.0.0.
If you must use legacy versions of Node.js, please use our binary installation methods. https://docs.bit.dev/docs/installation

As the error correctly notes, I am using Node 21.1.0 but that is above the range of Node versions that the install process supports. It would make sense to adjust the upper limit of supported Node versions.

I've tried many possible installation as below:
npm i -g teambit/bvm
npx teambit/bvm install

Check path on my env. variable. it has "C:/Users......./.bvm"
I close and open the terminal again to run bvm install. But it complains "bvm is not recognized as an internal or external command,
operable program or batch file."

Only thing is I open the ./bvm folder, I do not see any bvm file at all. Only bit and bit.cmd with 3 folders.

What do you think I missed?

OS: Windows 10 Enterprise (10.0.19045)
bvm v0.3.1
node v18.15.0
npm v9.5.0

I have multiple versions of bit installed:

➜ bvm list
0.0.888
0.1.11
0.1.4
0.1.7

The help text for bvm provides a broken example for removal (bvm remove all --keep-latest-versions 3). Running bvm remove -h, however, provides the proper --all switch syntax.

Running bit remove --all yields the following:

➜ bvm remove --all
⠹ removing versions from the file systemCannot read properties of undefined (reading 'removeVersions')
TypeError: Cannot read properties of undefined (reading 'removeVersions')
    at C:\ProgramData\nvm\v18.15.0\node_modules\@teambit\bvm\node_modules\@teambit\bvm.remove\dist\remove.js:65:21
    at Generator.next (<anonymous>)
    at fulfilled (C:\ProgramData\nvm\v18.15.0\node_modules\@teambit\bvm\node_modules\@teambit\bvm.remove\dist\remove.js:5:58)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
⠏ removing versions from the file system

After this, the command seems to be stuck in an infinite loop.

add checksum api

change to this filesystem structure:

└── bit
    ├── index.json
    └── versions
        └── 0.0.315
            ├── bit-0.0.315-darwin-x64.checksum.txt
            ├── bit-0.0.315-darwin-x64.tar.gz
            ├── bit-0.0.315-linux-x64.checksum.txt
            ├── bit-0.0.315-linux-x64.tar..gz
            ├── bit-0.0.315-win-x64.checksum.txt
            └── bit-0.0.315-win-x64.tar.gz

I recently upgraded from bit version 0.0.756 to 0.1.11 on my mac m1.

Prior to the upgrade I was able to do bit status and bit tag without any issues. After the upgrade to the latest version of bit some of the components present in the bit repo shows the following error when running bit status

Tracked component added as a package (either remove the package from the workspace.jsonc (bit uninstall) or remove the component (bit remove))

I tried the following steps

1. Deleting node modules folder and running bit install.
2. Removing the component (bit remove) and re adding it again using bit add. But this results in a new component being created and all the versions of the previous component are removed.

Describe the bug

After installing (or updating to the newest version), when I try to run bit tag I get an error:
Error: You installed esbuild on another platform than the one you're currently using. This won't work because esbuild is written with native code and needs to install a platform-specific binary executable.

For installing bit I've used the command from the documentation: npx @teambit/bvm install.

I've checked and Node.js is being installed in ~/.bvm/nodejs and it targets x64 instead of arm64, which is causing the issue.

Other bit commands also don't work correctly.

Steps to Reproduce

1. Install bit on mac with m1
2. Add a React component
3. Run bit tag

Expected Behavior

After installing or updating bit, it uses the correct build of Node.js for m1 architecture.

Specifications

• bvm: 0.1.7
• Bit version: 0.0.817
• Node version: 14.19.3
• yarn version: 1.18.0
• Platform: macos

Describe the bug

We are in the process of upgrading our tooling versions, including node to as latest version as possible. In our case this would be Node 19. We have updated our base docker images to derive from node:18-alpine. However, we are getting errors installing the latest version of bit cli within these images, relating to unsupported node version.

Steps to Reproduce

Build Docker image from node:19-alpine3.15 and install bit

FROM node:18-alpine
RUN @teambit/bvm@latest && bvm install 
Build image docker build .

Get following error
Node version 18.12.1 is not supported, please use Node.js >=14.19.3 <17.0.0.

Expected Behavior

Are there plans to support Node 18 (given that Node 19 is the current version)?

Specifications

Bit version:
Workspace type: (harmony/legacy) harmony
Node version: 18.12.1
Platform: alpine linux

When i run bvm install i get a quarantine message from microsoft defender saying bit-0.1.7-win-x64.tar.gz contains trojan

Hi I want to connect the bvm to my private registry in my private network and it seems to be coupled to the google api, so what I need to configure the bvm to some private registry that contains the required files?

when I do:
bvm install

this happens:
request to https://storage.googleapis.com/storage/v1/b/bvm.bit.dev/o?prefix=versions/dev/Windows_NT/ failed, reason: get addrinfo ENOTFOUND stoarge.googleapis.com

When I try to install Bit, I get error:

bvm install
unsupported platform windows_nt
Error: unsupported platform windows_nt
    at validatePlatform (C:\Users\dpetl\AppData\Local\Yarn\Data\global\node_modules\@teambit\bvm.list\dist\list.js:47:15)
    at getGcpList (C:\Users\dpetl\AppData\Local\Yarn\Data\global\node_modules\@teambit\bvm.list\dist\list.js:35:5)
    at C:\Users\dpetl\AppData\Local\Yarn\Data\global\node_modules\@teambit\bvm.list\dist\list.js:56:25
    at Generator.next (<anonymous>)
    at C:\Users\dpetl\AppData\Local\Yarn\Data\global\node_modules\@teambit\bvm.list\dist\list.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (C:\Users\dpetl\AppData\Local\Yarn\Data\global\node_modules\@teambit\bvm.list\dist\list.js:4:12)
    at listRemote (C:\Users\dpetl\AppData\Local\Yarn\Data\global\node_modules\@teambit\bvm.list\dist\list.js:55:12)
    at C:\Users\dpetl\AppData\Local\Yarn\Data\global\node_modules\@teambit\bvm.install\dist\install.js:49:75
    at Generator.next (<anonymous>)

I guess this is because of OS detects as windows_nt, not win.

/root/bin/bit: line 9: /root/.bvm/nodejs/16.15.1/bin/node: not found

A very popular distribution which is used to build (docker) images is Alpine. Alpine uses musl instead of glibc. The nodejs binary which is downloaded by bvm is linked to glibc and does not run/work on Alpine leading to the above error message.

Is it possible to make the download optional? Or check current node version and only install if different?

I've seen /root/bin/bit:

#!/bin/sh
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")

case `uname` in
    *CYGWIN*) basedir=`cygpath -w "$basedir"`;;
esac

export PATH="/root/.bvm/nodejs/16.15.1/bin:$PATH"
"/root/.bvm/nodejs/16.15.1/bin/node"  "$basedir/../.bvm/versions/0.0.775/bit-0.0.775/node_modules/@teambit/bit/bin/bit" "$@"
exit $?

By adding /root/.bvm/nodejs/16.15.1/bin to the front of the PATH, shell will try /root/.bvm/nodejs/16.15.1/bin/node first, so an absolute path is not necessary for the command itself. Just node would take the first "working" binary/executable in the PATH, using the 16.15.1 version for most of the users and "fallback" to the standard/installed versions for the rest of us.

I'm trying to install bit on my pc but the installation is stuck forever at downloading step after 1-2 mins of installation, tried multiple times with other node versions, turning off Windows Firewall, and Windows Security, but still gives the same result.
Steps to reproduce:

1. $npm install -g teambit/bvn
2. $bit install
   
   OS: Windows 11
   Node: v16.16.0

/usr/local/lib/node_modules/[@teambit](https://t.me/teambit)/bvm/node_modules/[@pnpm](https://t.me/pnpm)/fetch/lib/fetch.js:38
    const retryOpts = opts.retry ?? {};
                                  ^

SyntaxError: Unexpected token ‘?’
    at wrapSafe (internal/modules/cjs/loader.js:915:16)
    at Module._compile (internal/modules/cjs/loader.js:963:27)

I've been facing this issue in Jenkins build when using bvm during the bvm verions bvm install part

after installation of bvm no remotes are available to install
ran bvm install 1.2.0 which yields
(node:64642) [DEP0040] DeprecationWarning: The 'punycode' module is deprecated. Please use a userland alternative instead. (Use 'node --trace-deprecation ...' to show where the warning was created) version 1.2.0 not found on remote, use bvm list --remote to see available versions

bvm list -r
returns an empty table

attempted with node versions 18.x and 21.x
bvm - 1.0.3
bit - 1.6.140

A common practice is putting binaries into ~/.local/bin. Or at least put it into your already own and dot hidden ~/.bvm. The user's home directory belongs to, as the words imply, the user, not you.

#27 on the same matter received no response from the developers for SEVEN MONTHS. This is pure arrogance.

I can't initialize the workspace. Previously I ran "npx @teambit/bvm install" and when I ran "bit new hello-world-nextjs my-hello-world-nextjs --env teambit.community/starters/hello-world-nextjs" I have this error

add release type with array type

addReleaseType(version: string, releaseType: string)

removeReleaseType(version: string, releaseType: string)

need edit the index.json file per version

[
  {
    "version": "0.0.315",
    "date": "2022-03-17",
    "releaseType": ["nightly"]
  },
  {
    "version": "0.0.316",
    "date": "2022-03-18",
    "releaseType": ["stable", "nightly"]
  }
]

Running bvm install on the latest version on npm (0.0.30) produces garbage output

related to this commit in colors.js - Marak/colors.js074a0f8ed0c31c35d13d28632bd8a049ff136fb6

This will make sure that when running bit you will always have an exact version of node/git used by bit which reduces bugs and issues.

Does this package lack a package.json on purpose?

Creating a new issue from recent comments on issue #18 @GiladShoham

versions

bvm -v 0.0.30
node -v 16.13.0
npm -v 8.1.2

bvm config

{
  BVM_DIR: '...,
  DEFAULT_LINK: 'bit',
  'proxy.cert': 'Zscaler Root CA.pem',
  proxy: 'http://gateway.zscalerthree.net:8080'
}

error

% bvm install
request to https://storage.googleapis.com/storage/v1/b/bvm.bit.dev/o?prefix=versions/dev/Darwin/ failed, reason: unable to get local issuer certificate
FetchError: request to https://storage.googleapis.com/storage/v1/b/bvm.bit.dev/o?prefix=versions/dev/Darwin/ failed, reason: unable to get local issuer certificate
    at ClientRequest.<anonymous> (/Users/.../.nvm/versions/node/v16.13.0/lib/node_modules/@teambit/bvm/node_modules/node-fetch/lib/index.js:1461:11)
    at ClientRequest.emit (node:events:390:28)
    at TLSSocket.socketErrorListener (node:_http_client:447:9)
    at TLSSocket.emit (node:events:390:28)
    at emitErrorNT (node:internal/streams/destroy:157:8)
    at emitErrorCloseNT (node:internal/streams/destroy:122:3)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

additional information

• The pem file I'm passing to proxy.cert is a valid root certificate
• When browsing, the proxy correctly acknowledges the root cert and picks up 2 intermediate certificates
• If I paste in the URL above https://storage.googleapis.com/storage/v1/b/bvm.bit.dev/o?prefix=versions/dev/Darwin/ in my browser - I get a 200 ok and data back

It seems that the bvm install command is not getting the necessary intermediate certificates necessary from the proxy. But having said that I don't know enough about proxies in practice to know if that is accurate

I'm trying to install bit by following the documentation site but getting a fetching error with the second command!

npm i -g @teambit/bvm

/usr/local/bin/bvm -> /usr/local/lib/node_modules/@teambit/bvm/dist/app.js
npm WARN @teambit/[email protected] requires a peer of [email protected] but none is installed. You must install peer dependencies yourself
.
npm WARN @teambit/[email protected] requires a peer of @teambit/[email protected] but none is installed. You must install peer dependencies you
rself.
npm WARN @teambit/[email protected] requires a peer of [email protected] but none is installed. You must install peer dependencies yourself.

• @teambit/[email protected]
  updated 1 package in 17.88s

bvm install

request to https://bvm.bit.dev/versions/dev/Darwin/0.0.377/bit-0.0.377.tar.gz failed, reason: connect ECONNREFUSED 127.0.0.1:443
FetchError: request to https://bvm.bit.dev/versions/dev/Darwin/0.0.377/bit-0.0.377.tar.gz failed, reason: connect ECONNREFUSED 127.0.0.1:443
at ClientRequest. (/usr/local/lib/node_modules/@teambit/bvm/node_modules/node-fetch/lib/index.js:1461:11)
at ClientRequest.emit (events.js:315:20)
at TLSSocket.socketErrorListener (_http_client.js:469:9)
at TLSSocket.emit (events.js:315:20)
at emitErrorNT (internal/streams/destroy.js:106:8)
at emitErrorCloseNT (internal/streams/destroy.js:74:3)
at processTicksAndRejections (internal/process/task_queues.js:80:21)

Local Environment:
MacBook Pro with macOS Big Sur
npm version: 6.14.11

many times bvm remove is not deleting the versions from the fs.
Also during bvm upgrade, it should delete the previously used version from the fs, which doesn't happen.
It might be related to links that still exist in the fs from workspaces. see #21

At the moment when doing bvm link we create something like this
{linkName} -> {bvmFolder}/versions/{versionNumber}
for example:
bit -> ~/.bvm/versions/0.0.466
That means then if you install a new version of bit and remove the old one, the folder {bvmFolder}/versions/{versionNumber} doesn't exist anymore.
We do however have references to this folder - the links from any workspace to the core aspects looks like this:
node_modules/@teambit/{coreAspect} -> {bvmFolder}/versions/node_modules/@teambit/{coreAspect} which of course won't exist anymore, so you have to re-link everything.

Instead, it will be better to have a structure like this:
{linkName} -> {bvmFolder}/links/{linkName} -> {bvmFolder}/versions/{versionNumber}
for example:
node_modules/@teambit/{coreAspect} -> {bvmFolder}/links/{linkName}/@teambit/{coreAspect} -> {bvmFolder}/versions/node_modules/@teambit/{coreAspect}

Which means when installing a new version of bit and re-link we will only re-link this part:
before:
{bvmFolder}/links/{linkName} -> {bvmFolder}/versions/{versionNumber}
after (see the newVersionNumber):
{bvmFolder}/links/{linkName} -> {bvmFolder}/versions/{newVersionNumber}

This means no links will be breaking.