Currently, some of the modules depend on Javascript libraries grabbed from Node.js repositories.
Currently, such libraries aren't "shipped" with the application, and are to be placed, I guess manually, into .spacedoc/js/require. That is, going onto that directory, and running npm install ${package name here} .. The application itself has no way to install these dependencies on its own, which may or may not be a good thing.
The required dependencies aren't well documented anywhere, and are currently hardcoded into the WavedromJS and VizJS code.
The dependencies are the following, how-ever irrelevant it is:
- VizJS
viz.js
viz.js/full.render.js
- WavedromJS
Something should be done about this, to make it easier to run for other people, and so one doesn't have to have a .spacedoc directory somewhere with the exact same libraries all over. Those libraries may also use different version than what spacedoc expects, and as such it would concievably become quite a bit of a pain.
So, JS packages should then be packaged into the application jars/images somehow.
Currently, some of the modules depend on Javascript libraries grabbed from Node.js repositories.
Currently, such libraries aren't "shipped" with the application, and are to be placed, I guess manually, into
.spacedoc/js/require. That is, going onto that directory, and runningnpm install ${package name here} .. The application itself has no way to install these dependencies on its own, which may or may not be a good thing.The required dependencies aren't well documented anywhere, and are currently hardcoded into the WavedromJS and VizJS code.
The dependencies are the following, how-ever irrelevant it is:
viz.jsviz.js/full.render.jsjson5onmlSomething should be done about this, to make it easier to run for other people, and so one doesn't have to have a
.spacedocdirectory somewhere with the exact same libraries all over. Those libraries may also use different version than what spacedoc expects, and as such it would concievably become quite a bit of a pain.So, JS packages should then be packaged into the application jars/images somehow.