Install the latest Kubo (go-ipfs) binary:
# Install globally
> npm install -g kubo
> ipfs version
ipfs version v0.23.0
# Install locally
> npm install kubo
> ./node_modules/.bin/ipfs
ipfs version v0.23.0
This module downloads Kubo (go-ipfs) binaries from https://dist.ipfs.tech into your project.
It will download the kubo version that matches the npm version of this module. So depending on [email protected]
will install kubo v0.23.0
for your current system architecture, in to your project at node_modules/kubo/kubo/ipfs
and additional symlink to it at node_modules/kubo/bin/ipfs
.
On Windows, ipfs.exe
file is used, and if the symlink can't be created under a regular user, a copy of ipfs.exe
is created instead.
After downloading you can find out the path of the installed binary by calling the path
function exported by this module:
import { path } from 'kubo'
console.info('kubo is installed at', path())
An error will be thrown if the path to the binary cannot be resolved.
Downloaded archives are placed in OS-specific cache directory which can be customized by setting NPM_KUBO_CACHE
in env.
KUBO_BINARY
envIf the KUBO_BINARY
env variable is set at runtime this will override the path of the binary used.
This must point to the file, not the directory containing the file.
Warning: the file bin/ipfs
is a placeholder, when downloading stuff, it gets replaced. so if you run node install.js
it will then be dirty in the git repo. Do not commit this file, as then you would be commiting a big binary and publishing it to npm. A pre-commit hook exists and should protect against this, but better safe than sorry.
You should be able to just run ./publish.sh
for example:
> ./publish.sh
usage ./publish.sh <version>
publish a version of kubo to npm
> ./publish.sh 0.3.11
This will:
bin/ipfs
is right (must be the checked in file)package.json
and README.md
git commit
the changeskubo@$version
to https://npmjs.com/package/kubo
Open an issue in the repo if you run into trouble.
If some problem happens, and you need to publish a new version of this module targetting the same kubo version, then please follow this convention:
<kubo-version>
<kubo-version>-hacky<num>
Why do this?
Well, if you previously published npm module [email protected]
and there was a problem, we now must publish a different version, but we want to keep the version number the same. so the strategy is to publish as [email protected]
, and unpublish [email protected]
.
Why
-hacky<num>
?
Because it is unlikely to be a legitimate kubo version, and we want to support kubo versions like floodsub-1
etc.
Do i have to say
-hacky<num>
or can i just use-<num>
?
-<num>
won't work, as link-ipfs.js expects -hacky<num>
. If you want to
change the convention, go for it, and update this readme accordingly.
Feel free to join in. All welcome. Open an issue!
This repository falls under the IPFS Code of Conduct.