1 | <img style="width: 200px; height: 200px;" src="https://raw.githubusercontent.com/cytoscape/cytoscape.js/unstable/documentation/img/cytoscape-logo.png" width="200" height="200"></img>
|
2 |
|
3 | [![GitHub repo](https://img.shields.io/badge/Repo-GitHub-yellow.svg)](https://github.com/cytoscape/cytoscape.js)
|
4 | [![Twitter updates](https://img.shields.io/badge/Updates-Twitter-yellow.svg)](https://twitter.com/cytoscapejs)
|
5 | [![News and tutorials](https://img.shields.io/badge/News%20%26%20tutorials-Blog-yellow.svg)](https://blog.js.cytoscape.org)
|
6 | [![Questions at StackOverflow](https://img.shields.io/badge/Questions-StackOverflow-yellow.svg)](https://stackoverflow.com/questions/tagged/cytoscape.js)
|
7 | [![Ask a question at StackOverflow](https://img.shields.io/badge/Ask%20a%20question-StackOverflow-yellow.svg)](https://stackoverflow.com/questions/ask?tags=cytoscape.js,javascript)
|
8 | [![Community discussions](https://img.shields.io/badge/Community%20discussions-GitHub-yellow.svg)](https://github.com/cytoscape/cytoscape.js/discussions)
|
9 | [![License](https://img.shields.io/badge/License-MIT-blue.svg)](https://raw.githubusercontent.com/cytoscape/cytoscape.js/master/LICENSE)
|
10 | [![DOI](https://zenodo.org/badge/2255947.svg)](https://zenodo.org/badge/latestdoi/2255947)
|
11 | [![Cite](https://img.shields.io/badge/Cite-Oxford%20Bioinformatics%20Article-blue.svg)](https://js.cytoscape.org/#introduction/citation)
|
12 | [![npm](https://img.shields.io/npm/v/cytoscape.svg)](https://www.npmjs.com/package/cytoscape)
|
13 | [![Download](https://img.shields.io/npm/v/cytoscape.svg?label=Download)](https://github.com/cytoscape/cytoscape.js/tree/master/dist)
|
14 | [![Extensions](https://img.shields.io/badge/Extensions-67-blue.svg)](https://js.cytoscape.org/#extensions)
|
15 | [![npm installs](https://img.shields.io/npm/dm/cytoscape.svg?label=npm%20installs)](https://www.npmjs.com/package/cytoscape)
|
16 | [![Automated tests](https://github.com/cytoscape/cytoscape.js/actions/workflows/tests.yml/badge.svg)](https://github.com/cytoscape/cytoscape.js/actions/workflows/tests.yml)
|
17 |
|
18 | # Cytoscape.js
|
19 |
|
20 | Graph theory (network) library for visualisation and analysis : [https://js.cytoscape.org](https://js.cytoscape.org)
|
21 |
|
22 | ## Description
|
23 |
|
24 | Cytoscape.js is a fully featured [graph theory](https://en.wikipedia.org/wiki/Graph_theory) library. Do you need to model and/or visualise relational data, like biological data or social networks? If so, Cytoscape.js is just what you need.
|
25 |
|
26 | Cytoscape.js contains a graph theory model and an optional renderer to display interactive graphs. This library was designed to make it as easy as possible for programmers and scientists to use graph theory in their apps, whether it's for server-side analysis in a Node.js app or for a rich user interface.
|
27 |
|
28 | You can get started with Cytoscape.js with one line:
|
29 |
|
30 | ```js
|
31 | var cy = cytoscape({ elements: myElements, container: myDiv });
|
32 | ```
|
33 |
|
34 | Learn more about the features of Cytoscape.js by reading [its documentation](https://js.cytoscape.org).
|
35 |
|
36 |
|
37 | ## Example
|
38 |
|
39 | The Tokyo railway stations network can be visualised with Cytoscape:
|
40 |
|
41 | <img style="width: 300px; height: 126px;" src="https://raw.githubusercontent.com/cytoscape/cytoscape.js/unstable/documentation/img/tokyo-big.png" width="300" height="126"></img>
|
42 |
|
43 | <img style="width: 300px; height: 126px;" src="https://raw.githubusercontent.com/cytoscape/cytoscape.js/unstable/documentation/img/tokyo-big-zoomed-in.png" width="300" height="126"></img>
|
44 |
|
45 | A [live demo](https://js.cytoscape.org/demos/tokyo-railways/) and [source code](https://github.com/cytoscape/cytoscape.js/tree/master/documentation/demos/tokyo-railways) are available for the Tokyo railway stations graph. More demos are available in the [documentation](https://js.cytoscape.org/#demos).
|
46 |
|
47 |
|
48 | ## Documentation
|
49 |
|
50 | You can find the documentation and downloads on the [project website](https://js.cytoscape.org).
|
51 |
|
52 |
|
53 |
|
54 | ## Roadmap
|
55 |
|
56 | Future versions of Cytoscape.js are planned in the [milestones of the Github issue tracker](https://github.com/cytoscape/cytoscape.js/milestones). You can use the milestones to see what's currently planned for future releases.
|
57 |
|
58 |
|
59 |
|
60 |
|
61 | ## Contributing to Cytoscape.js
|
62 |
|
63 | Would you like to become a Cytoscape.js contributor? You can contribute in technical roles (e.g. features, testing) or non-technical roles (e.g. documentation, outreach), depending on your interests. [Get in touch with us by posting a GitHub discussion](https://github.com/cytoscape/cytoscape.js/discussions).
|
64 |
|
65 | For the mechanics of contributing a pull request, refer to [CONTRIBUTING.md](.github/CONTRIBUTING.md).
|
66 |
|
67 | Feature releases are made monthly, while patch releases are made weekly. This allows for rapid releases of first- and third-party contributions.
|
68 |
|
69 |
|
70 |
|
71 | ## Citation
|
72 |
|
73 | To cite Cytoscape.js in a paper, please cite the Oxford Bioinformatics issue:
|
74 |
|
75 | *Cytoscape.js: a graph theory library for visualisation and analysis*
|
76 |
|
77 | Franz M, Lopes CT, Huck G, Dong Y, Sumer O, Bader GD
|
78 |
|
79 | [Bioinformatics (2016) 32 (2): 309-311 first published online September 28, 2015 doi:10.1093/bioinformatics/btv557 (PDF)](https://bioinformatics.oxfordjournals.org/content/32/2/309)
|
80 |
|
81 | [PubMed Abstract](https://www.ncbi.nlm.nih.gov/pubmed/26415722)
|
82 |
|
83 |
|
84 |
|
85 |
|
86 | ## Build dependencies
|
87 |
|
88 | Install `node` and `npm`. Run `npm install` before using `npm run`.
|
89 |
|
90 |
|
91 |
|
92 |
|
93 | ## Build instructions
|
94 |
|
95 | Run `npm run <target>` in the console. The main targets are:
|
96 |
|
97 | **Building:**
|
98 |
|
99 | * `build`: do all builds of the library (umd, min, umd, esm)
|
100 | * `build:min` : do the unminified build with bundled dependencies (for simple html pages, good for novices)
|
101 | * `build:umd` : do the umd (cjs/amd/globals) build
|
102 | * `build:esm` : do the esm (ES 2015 modules) build
|
103 | * `clean` : clean the `build` directory
|
104 | * `docs` : build the docs into `documentation`
|
105 | * `release` : build all release artifacts
|
106 | * `watch` : automatically build lib for debugging (with sourcemap, no babel, very quick)
|
107 | * good for general testing on `debug/index.html`
|
108 | * served on `http://localhost:8080` or the first available port thereafter, with livereload on `debug/index.html`
|
109 | * `watch:babel` : automatically build lib for debugging (with sourcemap, with babel, a bit slower)
|
110 | * good for testing performance or for testing out of date browsers
|
111 | * served on `http://localhost:8080` or the first available port thereafter, with livereload on `debug/index.html`
|
112 | * `watch:umd` : automatically build prod umd bundle (no sourcemap, with babel)
|
113 | * good for testing cytoscape in another project (with a `"cytoscape": "file:./path/to/cytoscape"` reference in your project's `package.json`)
|
114 | * no http server
|
115 | * `dist` : update the distribution js for npm etc.
|
116 |
|
117 | **Testing:**
|
118 |
|
119 | The default test scripts run directly against the source code. Tests can alternatively be run on a built bundle. The library can be built on `node>=6`, but the library's bundle can be tested on `node>=0.10`.
|
120 |
|
121 | * `test` : run all testing & linting
|
122 | * `test:js` : run the mocha tests on the public API of the lib (directly on source files)
|
123 | * `npm run test:js -- -g "my test name"` runs tests on only the matching test cases
|
124 | * `test:build` : run the mocha tests on the public API of the lib (on a built bundle)
|
125 | * `npm run build` should be run beforehand on a recent version of node
|
126 | * `npm run test:build -- -g "my test name"` runs build tests on only the matching test cases
|
127 | * `test:modules` : run unit tests on private, internal API
|
128 | * `npm run test:modules -- -g "my test name"` runs modules tests on only the matching test cases
|
129 | * `lint` : lint the js sources via eslint
|
130 | * `benchmark` : run all benchmarks
|
131 | * `benchmark:single` : run benchmarks only for the suite specified in `benchmark/single`
|
132 |
|
133 |
|
134 |
|
135 | ## Release instructions
|
136 |
|
137 | 1. Ensure the docs are updated with the list of releases you would like to make in `documentation/md/intro.md` (on both `master` and `unstable` branches). Push the changes.
|
138 | 1. Ensure that [milestones](https://github.com/cytoscape/cytoscape.js/milestones) exist for the releases that you would like to make. Each milestone should contain its corresponding issues and pull requests.
|
139 | 1. For patch releases, do the back-port patch release before the corresponding current release. This ensures that npm lists the current version as the latest one.
|
140 | 1. `git checkout 1.1.x`, e.g. if the previous feature release is 1.1
|
141 | 1. Follow the remaining ordinary release steps (step 5 and onward).
|
142 | 1. Current releases are based on the `master` branch: `git checkout master`
|
143 | 1. If you are making a patch release, you can just release `master` with its new patches.
|
144 | 1. If you are making a feature release, you need to merge `unstable` onto `master`. Since there can be conflicts, it's easiest to use the 'ours' strategy which will allow you to use the state of `unstable` as-is (i.e. no conflict resolution necessary):
|
145 | 1. Make sure your local `master` is up-to-date: `git checkout master && git pull`
|
146 | 1. Make sure your local `unstable` is up-to-date: `git checkout unstable && git pull`
|
147 | 1. Create a merge commit that selects the state of `unstable` and push it: `git merge -s ours master && git push`
|
148 | 1. Fast-forward `master` to the merge commit: `git checkout master && git merge unstable && git push`
|
149 | 1. Update the version number in `package.json` and `package-lock.json` on `unstable` to some provisional new version number, and push it.
|
150 | 1. Update the `VERSION` environment variable for the release number you want to make, e.g. `export VERSION=1.2.3`
|
151 | 1. Confirm all the tests are passing:
|
152 | 1. `npm run test`
|
153 | 1. See also `test/index.html` for browser testing (optional)
|
154 | 1. Confirm all the tests are passing in IE9 (for feature releases):
|
155 | 1. `npm run watch:umd`
|
156 | 1. Open an [IE9 VM](https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/)
|
157 | 1. Open `http://yourip:8081/test/ie.html` in IE
|
158 | 1. Prepare a release: `npm run release`
|
159 | 1. Review the files that were just built in the previous step.
|
160 | 1. There should be a series of updated files in the `dist` directory and the `documentation` directory, identified with `git status`.
|
161 | 1. Try out the newly-built docs and demos in your browser.
|
162 | 1. Add the the release to git: `git add . && git commit -m "Build $VERSION"`
|
163 | 1. Update the package version and tag the release: `npm version $VERSION`
|
164 | 1. Push the release changes: `git push && git push --tags`
|
165 | 1. Publish the release to npm: `npm publish`
|
166 | 1. [Create a release](https://github.com/cytoscape/cytoscape.js/releases/new) for Zenodo from the latest tag. Make sure you wait at least 5 minutes since the last time that you made a release in order for Zenodo to work properly.
|
167 | 1. For feature releases: Create a release announcement on the [blog](https://github.com/cytoscape/cytoscape.js-blog). Share the announcement on mailing lists and social media.
|
168 |
|
169 |
|
170 |
|
171 | ## Tests
|
172 |
|
173 | Mocha tests are found in the [test directory](https://github.com/cytoscape/cytoscape.js/tree/master/test). The tests can be run in the browser or they can be run via Node.js (`npm run test:js`).
|