Contributing

Contributions to Paths.js are always welcome! If you feel like helping, be sure to contact me through Github, so that efforts are not duplicated.

The library is currently written in Coffeescript. If you are a Javascript user, don't be scared: it should only take a rapid tour to get you acquainted with the language, as it is semantically very similar to Javascript.

If you do not feel like contributing to the library directly, you can always help by spreading the word, or by improving the demo. I am also developing another demo, based on React.

How can I help?

There are a few things that Paths.js still needs; I will try to keep an updated list here. Of course, other contributions are also welcome - this is just the list of the stuff that I have in mind.

Improve an existing chart

First, there are improvements to be made to existing charts. In particular, the Graph chart is currently pretty slow and unoptimized. This chapter has an overview of existing algorithms for force-directed networks layout, and it would be nice to try out some of the ideas in there. The tree layout algorithm is also quite simplistic in its current implementation, and this chapter features a few possible improvements.

Create a new chart

There are some charts that are still missing from Paths.js, in particular Voronoi diagrams, circle packings and the Circos diagram.

Improve testing and documentations

This does not need much explanation. :-) In particular, I would be happy to receive feedback on how the documentation can be improved. As the author of the library, I happen to understand how to use it fairly well, but I am sure there are pitfalls for beginners.

New general features

I have been tinkering with the idea of allowing arbitrary 2d transformations to be applied to points just before computing the paths. This would allow, for instance, to add a fisheye effect to existing graphs.

Porting to other languages

There are bindings to use Paths.js with Scala.js. A nice contribution would be to create bindings for other languages, such as ClojureScript or TypeScript.

Workflow

You can use whatever workflow seems reasonable, but I find that the simplest way to develop Paths.js is the following:

• first, I develop a new chart by working directly in the demo application and checking that everything works correctly there
• then, I move the chart to a local copy of the Paths.js repository, and fix the relative imports if necessary
• while still working locally, I commit the chart and tag it
• I point the demo application to the local copy of Paths.js and check that everything still works correctly
• if not, I remove the local tag, fix what needed and repeat
• when it works, I still remove the tag and add tests
• when tests are ok, I update the version in bower.json and package.json, make the final commit of the feature and add the tag

I know this is cumbersome, but I have not found a more sane way to keep the library and demo separated. Ideally, I would use some kind multiproject configuration, but it seems that Bower does not support such cases. The intermediate adding and removal of git tags is needed to make Bower recognize the existence of a new version.

Any suggestions to improve the workflow are welcome!

Guidelines

There are not many restrictions on how to contribute. Just be sure to follow the general philosophy and add tests for your work (see the existing tests as an example).

Paths.js does not currently depend on external libraries, and it will remain so. There are a couple of reasons for this:

• it is currently very hard to provide a library that depends on third-party libraries in a Javascript environment, while still making sure that this will work with both AMD or Common.js modules, and also as a standalone script
• it helps to keep the size of the library reasonable

Personally, I would have benefited from a collection library, such as Ramda or Lodash, but Coffeescript list comprehensions and ES5 Array methods make this more tolerable.