Security News
JSR Working Group Kicks Off with Ambitious Roadmap and Plans for Open Governance
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
Provides read-only bindings to the Open Source Routing Machine - OSRM, a routing engine for OpenStreetMap data implementing high-performance algorithms for shortest paths in road networks.
build config | status |
---|---|
Linux/OS X |
C++11 capable platforms include:
An installation error like below indicates your system does not have a modern enough g++ toolchain:
Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.17' not found (required by /node_modules/osrm/lib/binding/osrm.node)
If you are running Ubuntu older than 14.04 you can easily upgrade your g++ toolchain like:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install g++-4.8
By default, binaries are provided for:
On those platforms no external dependencies are needed.
Just do:
npm install osrm
However other platforms will fall back to a source compile: see Source Build for details.
See the example/server.js
and test/osrm.test.js
for examples of using OSRM through this Node.js API.
The node-osrm
module consumes data processed by OSRM core.
This repository contains a Makefile that does this automatically:
Just run:
make test
Once that is done then you can calculate routes in Javascript like:
You can build from source by using mason. Just go to your node-osrm folder and run:
make
This will download and build the current version of osrm-backend and set all needed variables.
Then you can test like
make test
To rebuild node-osrm after any source code changes to src/node_osrm.cpp
simply type again:
make
If you wish to have a different version of osrm-backend build on the fly, change the osrm_release
variable in package.json
and rebuild:
make clean
make && make test
If you do not wish to build node-osrm against an existing osrm-backend that you have on your system you will need:
make -C test/data
inside the osrm-backend
directorySee Project-OSRM wiki for details.
Once Project-OSRM is built you should be able to run:
pkg-config libosrm --variable=prefix
Which should return the path to where you installed Project-OSRM.
Now you can build node-osrm
:
git clone https://github.com/Project-OSRM/node-osrm.git
cd node-osrm
npm install --build-from-source
To run the tests against your local osrm-backend's data you will need to
set the OSRM_DATA_PATH
variable:
export OSRM_DATA_PATH=/path/to/osrm-backend/test/data
Then you can run npm test
.
To recap, here is a full example of building against an osrm-backend that is cloned beside node-osrm but installed into a custom location:
export PATH=/opt/osrm/bin:${PATH}
export PKG_CONFIG_PATH=/opt/osrm/lib/pkgconfig
pkg-config libosrm --variable=prefix
# if boost headers are in a custom location give a hint about that
# here we assume the are in `/opt/boost`
export CXXFLAGS="-I/opt/boost/include"
npm install --build-from-source
# build the osrm-backend test data
make -C ../osrm-backend/test/data
export OSRM_DATA_PATH=../osrm-backend/test/data
npm test
After setting up a Source Build you can make changes to the code and rebuild like:
npm install --build-from-source
But that will trigger a full re-configure if any changes occurred to dependencies.
However you can optionally use the Makefile which simplifies some common needs.
To rebuild using cached data:
make
If you want to see all the arguments sent to the compiler do:
make verbose
If you want to build in debug mode (-DDEBUG -O0) then do:
make debug
Under the hood this uses node-pre-gyp (which itself used node-gyp) to compile the source code.
Run the tests like:
make test
Releasing a new version of node-osrm
is mostly automated using travis.ci.
Confirm the desired OSRM branch and commit.
This is configurable via the OSRM_BRANCH
and OSRM_COMMIT
variables in the .travis.yml
.
Bump node-osrm version
Update the CHANGELOG.md
and the package.json
version if needed.
Check Travis.ci
Ensure Travis.ci builds are passing after your last commit.
Publishing binaries
If travis builds are passing then it's time to publish binaries by committing with a message containing [publish binary]
. If you don't have anything to commit then you can do:
git commit --allow-empty -m "[publish binary]"
Test
Locally you can now test binaries. Cleanup, re-install, and run the tests like:
make clean
npm install # will pull remote binaries
npm ls # confirm deps are correct
make test
Confirm the remote binaries are available by running node-pre-gyp locally:
$ ./node_modules/.bin/node-pre-gyp info --loglevel silent | grep `node -e "console.log(require('./package.json').version)"`
osrm-v0.2.8-node-v11-darwin-x64.tar.gz
osrm-v0.2.8-node-v11-linux-x64.tar.gz
Tag
Once binaries are published for Linux and OS X then its time to tag a new release:
git tag v0.2.8 -m "Tagging v0.2.8"
git push --tags
Publish node-osrm
First ensure your local node-pre-gyp is up to date:
npm ls
This is important because it is bundled during packaging.
If you see any errors then do:
rm -rf node_modules/node-pre-gyp
npm install node-pre-gyp
Now we're ready to publish node-osrm
to https://www.npmjs.org/package/osrm:
npm publish
Dependent apps can now pull from the npm registry like:
"dependencies": {
"osrm": "~0.2.8"
}
Or can still pull from the github tag like:
"dependencies": {
"osrm": "https://github.com/Project-OSRM/node-osrm/tarball/v0.2.8"
}
FAQs
The Open Source Routing Machine is a high performance routing engine written in C++14 designed to run on OpenStreetMap data.
We found that osrm demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 21 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.
Security News
Research
Attackers are impersonating Sindre Sorhus on npm with a fake 'chalk-node' package containing a malicious backdoor to compromise developers' projects.