Standalone umd

[johnwebbcole]

#402, #344, #343, #300 and possibly others.

Standalone UMD Build

This adds two files for a new build target with the --standalone switch. It creates a UMD version of OpenJSCAD that can be loaded with other bundlers or embedded in another web application with a script tag.

These changes were not possible a few months ago, but the fantastic work being done to provide a common core based on the @jscad libraries has really paid off. This MR does not replace or impact the #382 overhaul, it is intended to leverage exiting changes to give a web installable version. It's my hope that #382 will include a UMD build as well when it is complete.

Here is an example site using the UMD build: https://johnwebbcole.gitlab.io/vesa-shelf/

umd.js and processor-bare.js

The two new files build on opt.js and processor.js to provide a minimal export function that allows
an application to create a jscad viewer. I have been able to create a vue component that allows you to include a .jscad file in a vuepress static site. The vesa-shelf project inclues a gitlab cicd file that creates a gitlab pages (similar to github pages) site using vuepress. https://johnwebbcole.gitlab.io/vesa-shelf/ uses the umd build (I published a version under my scope, @jwc/jscad-web to try it out) which gives me a way to publish live versions of a project, without relying on the public https://openjscad.org/ site.

I plan on publishing a vue-openjscad package, based on the code in vesa-shelf using a UMD build soon.

I'll also update the yeoman generator-jscad with an option to generate the vuepress site using the vue-openjscad package.

eslint and prettier files

These were added to prevent vscode from auto formatting the base @jscad files. I'll happily remove these if desired.

postInstall.js

When loading the @jscad/web package, the postInstall step throws an error because the examples aren't loaded. Added a check for the examples directory to get around this issue.

jscad-viewer-lightgl.js

Fixed a cut and paste issue, it was generating weird html in the viewerdiv element.

Why modify the 1.x version?

So why allow a change in 1.x? Here are a few reasons I hope will persuade everyone.

The web overhaul for the 2.x version is looking great. I'm looking forward to it, but it's not ready yet, and there is no need to rush anything.

Having an embeddable version of the 1.x branch provides a lot of insulation for the new 2.x site. If a project encounters issues with the new 2.x website, you can create an embedded version of the 1.x site.

In my opinion, the lack of an embeddable version is a primary reason against adoption of OpenJSCAD. The main libraries are starting to see adoption because they are reusable. I think the same will happen with a reusable viewer also.

And finally, these are minor changes, reusing existing code and almost no changes to existing files (except for the bug fixes). I think making a 1.10.0 version adding this feature will not impact on the existing code base, nor complicating the 2.x efforts.

Changes

fixed bug in packages/web/postInstall.js that prevented installing @jscad/web,
when the examples were not loaded.

Adds a umd build target based on opt.js. umd.js and processor-bare.js
are usable by different bundlers like webpack.

Added eslint and prettier config files to prevent vscode from automatically formatting
exsiting OpenJsCad files.

All Submissions:

• Have you followed the guidelines in our Contributing document? Let me know if I missed something.
• Have you checked to ensure there aren't other open Pull Requests for the same update/change? feat(all): Overhaul and V2 groundwork #382 is a complete overhaul with work continuing.
• Does your submission pass tests? (jscad to amf(with transparency) fails in master also)

Note: please do NOT include build files (those generate by the build-xxx commands) with your PR,

Thank you for your help in advance, much appreciated !

[kaosat-dev]

Thanks for the huge PR @johnwebbcole !

Standalone UMD Build

• the goal of this is lofty, I can only agree even though I will have some headaches with this vs V2 :D
• very nice & fast example , big kudos !
• I am drowning in the scope of the feat(all): Overhaul and V2 groundwork #382 overhaul so I understand the need to have something 'now', and yes it will / does have something like umd (ability to load as script for simple use etc)
• I see the CI build is failing because of node-sylvester I have not looked into what/how exactly yet, I am guessing it is related to what we discussed about the scad translator ?

umd.js and processor-bare.js

• very nice work !
• vuepress seems close to gatsby ? (Even if I use vue everyday at work I remain more of a React person, sorry , haha)
• vue-openjscad: could you please clarify what this would include ? (scope etc)

eslint and prettier files

• thanks but sorry I really do not think they belong in this PR , also another note : we use standard.js formatting in general (like https://github.com/jscad/io/blob/V2/package.json#L50), we can switch to more strict linting in V2 but for now really the least of our worries :), so please remove them for now

postInstall.js

• hmm could you clarify in what case there would not be examples present ? not sure I follow

jscad-viewer-lightgl.js

• groovy thanks !

Why modify the 1.x version?

• I can completely understand the logic behind it, I really wish V2 was closer to release but we are just not there yet. I feel guilty about not merging some PRs for V1 because it adds too much issues to keep working on two major versions. I think, given that this does not normally break or change things significantly that we could merge (after fixing some of the issues)

General

• going through the changed / added files now. I'll get back to you once I groked it all :)

[johnwebbcole]

@kaosat-dev hey, thanks for all your hard work too... as I mentioned, a clean UMD module wasn't really possible earlier.

VuePress is indeed a lot like Gatsby but not quite as extensive.

The vue component package will be a lot like the open-jscad.vue component in the vesa-shelf project. Its used in the README.md file

<open-jscad design="vesa-shelf.jscad" :panel="{size:223}" :camera="{position: {x: 0, y: 0, z: 223},clip: {min: 1, max: 1000}}"></open-jscad>

And handles resizing and update isolation (so Vue won't re-render a section, React has the same guards). I think a React component package should be just as easy. I'm not a React expert, so I'll leave that one up to you :-)

I would appreciate some help getting the test working, I'm not sure what was wrong there. The master branch has the same error.

I've pulled the eslint and prettier config files. Though it may be a good idea to add them in the future, even if they are telling it NOT to run on files. :-) I had them in so VSCode wouldn't reformat everything.

If you see any changes that can be made to make V2 issues easier, let me know.

[kaosat-dev]

@johnwebbcole ah ok, I see nice and clean vue component you got there ! I usually prefer more 'vanilla' js functions instead of components/custom elements, but the one you have is really nice !
Ironically I got to use React a lot less than Vue, so not so sure about react components haha :) (then again I absolutely love the new react 'hooks' , but I disgress

• about the tests/ sylvester I have a horrible suspicion that I am the one at fault : might be due to the package name change I had to do for the (scoped) npm publish last night, yikes ! this also shows I should have at the very least have used a tagged git version or a branch in the dependencies. I will look into it now
• thanks for removing the linting stuff for now :)

• If you see any changes that can be made to make V2 issues easier, let me know.

not quite sure : we could make some changes to make it closer to V2 , then again, that might be premature, and since V2 is a breaking version, perhaps just not worth the hassle

[kaosat-dev]

@johnwebbcole could you please bump the dependencies on the translator module to 0.0.11 ?
I just released a fixed version : https://www.npmjs.com/package/@jscad/openscad-openjscad-translator

[kaosat-dev]

what is the status for the support of the 'module' field ? I used to use it a few years back, then it seemed to go out of fashion and now is back again (saw some es module listings using it to get all npm modules with direct import support)

[johnwebbcole]

Rollup, Webpack and Browserify to an extent use this during bundling. The "browser" field is the standard one, but will fall back to "main" if it doesn't exist. "module" tells the major bundlers to use that file instead of attempting to use the src files (which aren't set).

The upshot is that you can use an import like:

const openjscad = require('@jscad/web')

instead of

const openjscad = require('@jscad/web/dist/openjscad.umd.js')

And if we decide to change the default exported file, we can control that without everyone
chaging their import/requires.

"module" will get skipped by node, and the browsers.

[kaosat-dev]

yay, thanks for updating ! tests are now passing, will try to merge either tonight or tomorrow at the latests.

[kaosat-dev]

@johnwebbcole I wanted to merge this morning, but took a closer look at everything : would you mind discussing the points I mentioned before we can merge ? Thanks !
And sorry, not wanting to nitpick, but I think they are point worth digging a bit more into.

[BarbourSmith]

As someone following along from the sidelines thank you for an excellent pull request and an excellent review process. These changes help me a lot, and I am impressed with the way this project is being run.