Move OpenJSCAD.org to NPM and / or Some Other Package Manager

[z3dev]

There are plenty... Hopefully, a few top candidates will be found for both scripts and browsers.

[richievos]

Maybe it'd be useful to document a couple use cases. I have a couple things in the package realm I'd like to see happen with this toolset.

Some use cases

Have a local viewer optimized for quick display

This one isn't that different from the existing OpenJSCAD webiste, but I'd really like to be able to run "some_command my_file_or_directory" and have it pop open a viewer of the file (or the main in the directory). This currently exists in the OpenJSCAD website, but the website is built around someone exploring / playing around, and has things that aren't super useful for me working locally (eg showing the text).

This would of course continue to auto reload / auto re-render. Again, this is very similar to the existing UI, but with some of the extras ripped out, optimized for the "I have my text editor open and this viewer both open" case.

Streamline the OpenJSCAD install

git clone followed by make install's not bad, but it'd be nice if it was just "blah install openjscad", with explicit versions. Preferably that'd install the command line converter, viewer(s), and all the dependencies (without them all having to manually copy pasted / checked in).

Versioning OpenJSCAD

OpenJSCad and the dependencies will change over time. Many of those changes will be minor bugfixes and backwards compatible feature adds. Not all would be (for instance some of the thread around format.js and the export code).

It'd be nice if I could be working on my model, and be able to pull updates following Semantic Versioning patterns, so I can trust (hope?) all my stuff continues to work (per versioning rules).

Set the groundwork for jscad library dev

This is my real pipe dream. I think it's bad that the state of the art for model / component is going to thingiverse, using their customizer or otherwise hoping you find some code you can steal. The jscad ecosystem should be like the rest of the javascript one.

People should be distributing screws.js as a open source collection of screws. Cubes/rects with rounded corners should be a default library people pull in. I should be reusing whatever javascript frameworks out there I need to pull it off.

I think a big enabler to that is getting a distribution mechanism in place for sharing that. That's something that could be built, but given this is all based around javascript, why not just reuse those?

So what to use?

I'm not super sure. For me the big focus would be on the local development model. I think the web one is very important too, but I have to imagine most real uses of OpenJSCAD are not using the website to build their models. They're using their favorite text editor and then kicking off the viewer against it.

[z3dev]

Maybe it would be helpful to review where OpenJSCAD is today?

• Libraries
  • jQuery (DOM manipulations and query)
  • Hammer (for touch screens)
  • ACE (for in-browser editor)
  • lightgl (for rendering to the GL canvas)
  • CSG.js (for 2D/3D model structures and functions)
  • formats.js (for conversion between external storage formats)
• OpenJSCAD
  • doc/ (is this maintained? i think the WIKI is the new source of documentation)
  • examples/ (various examples)
  • imgs/ (images for viewer)
  • index.html (container for processor/viewer)
  • openjscad (NODE script for converting between formats)
  • openjscad.css
  • openjscad.js (Processor, Viewer, BLOB conversions, file export, etc)
  • openscad-openjscad-translator.js (JS script, not maintained??)
  • openscad.js (OpenSCAD-like functions, math functions, color functions, file conversions)
  • remote.pl (PERL script to fetch files into a directory, which can then be "included")
  • style.css

I think we should start by making this look like a "standard" project. I suggest following CommonJS or another similar standard. I have a feeling this will require some changes to classes. http://wiki.commonjs.org/wiki/Packages/1.0

And of course, the new project should support use by browsers as well as NODEJS.

Where do you want to start?

[z3dev]

CommonJS is more than that - it's a project to define a common API and ecosystem for JavaScript. One part of CommonJS is the Module specification. Node.js and RingoJS are server-side JavaScript runtimes, and yes, both of them implement modules based on the CommonJS Module spec.

AMD (Asynchronous Module Definition) is another specification for modules. RequireJS is probably the most popular implementation of AMD. One major difference from CommonJS is that AMD specifies that modules are loaded asynchronously - that means that modules are only loaded as they are needed, as opposed to loading all modules up front.

AMD is generally more used in client-side (in-browser) JavaScript development due to this, and CommonJS Modules are generally used server-side. However, you can use either module spec in either environment - for example, RequireJS offers directions for running in Node.js, and browserify is a CommonJS Module implementation that can run in the browser.

That's from stackoverflow.com... But gives a pretty good picture of what we should be working towards.

I have already worked with RequireJS today, and was successful in defining the dependencies for OpenSCAD.org. But this required 'shim' definitions which are not required if a library has the proper "handles" for the project manager.

Can you try the same with Browserify, which seems very popular?

[z3dev]

@Spiritdude We need a branch for coordinating changes and testing. Can you make this soon? Thanks

[Spiritdude]

@z3dev just made new 'dev' branch. Ok?

[z3dev]

@richievos what's your status now? i finally put together a pull request for the latest version of CSG.js and formats.js. It includes a full update of the ACE editor as well.

Please sync your forks / branches to this.

[runvnc]

I was thinking of breaking this up into modules that I could use with npm. So like npm install --save jscad; npm install --save jscad-lumber then

var cad = require('jscad'),
     _ = require('jscad-lumber);
var frame = [_2x4.translate([0,10,0])];
frame.render('frame.stl');

[z3dev]

Welcome to OpenJSCAD, @runvnc!

There's a lot to do in this space. The first step would be to break out the "core" JSCAD routines from utilities, SCAD, etc. There's a lot of mixing of functionality.

@Spiritdude and I are still correcting a few regressions with the DEV branch. If you want to take a shot at NPM'ify the core then please fork and work on the DEV branch.

If you get stuck then please feel free to chat via mail.

[rimmartin]

The move to npm on hold? Also just exploring for a couple of hours it looks like this project could be an organization for example like strider and cloud9

[z3dev]

@rimmartin thanks for the interest The move to NPM is basically on hold right now. I've been re-organizing the source code into modules, which will allow for better packaging via NPM, Browserify, etc. All the changes are being merged into the DEV branch. I have one or two more major pieces to break out. After that, we could use come help to complete this part.

[kaosat-dev]

Any news on this ? I am willing to do a lot of work in this area if needed (I create/code npm based , browserified packages on a daily basis).

[dav-m85]

There have been a lot of impressive work on the dev branch, however I am worried looking at how it diverged from master (about 400kLOC according to my git-diff --stat). What is the point to reach in order to merge it back ?

I'm sure we are many here wanting to help making it happen.

[z3dev]

@dav-m85 Please feel free to jump in. We are now keeping the DEV branch up to date as much as possible, so if you can scyncronize frequently then your changes can be added easily.

@kaosat-dev has just started a new PR to test the API of the 2D and 3D primitives. And I'm concentrated on making the re-organization practical in the browsers again. It's still a little early but I think this will be a significant step forward for both worlds.

[kaosat-dev]

@dav-m85 the restructuring was significant, but don't be scared , the LOC divergence is mostly due to :

• removing all the external libraries (jquery is completely gone as a dependency, and all the others are now included via npm , so not part of the files here anymore)
• spliting up of the huge files like openjscad.js , openscad.js etc into smaller , more specialized modules

I have tested the new codebase in Chrome, Firefox & Safari, I might have missed a few things, but everything should work as before (as Users go) except for these :

• openscad to to openjscad is broken, because of issues with the openscad-to-openjscad translator looking into ways of fixing this
• file caching for 'includes' etc is broken, but should not really be visible
• this one is unclear if it stems from the refactor, but mobile camera controls might be broken

[kaosat-dev]

every sub package and OpenJScad itself is now on npm https://www.npmjs.com/org/jscad is tested and validated since v1.0.0 ! Enjoy