jscad-web: http server

[platypii]

This PR adds a minimal web server using the built in node http package (who needs dependencies anyway?)

It can be run with npm run serve

It also adds the neat feature from JSCAD v2 where you can load a script by url like:

https://jscad.app/#https://raw.githubusercontent.com/gilboonet/designs/master/2023/demo_creeMeuble2.js (@gilboonet)

This required the following changes:

• add serve.js which starts a minimal http server
• handle serving static files from the build dir
• handle index.html as default file
• handle /remote endpoint which proxies fetch requests to cross domain urls
• handle /docs redirect to /docs/
• handle missing files, urls, etc
• handle mimetype detection
• server request logging
• client side checking for #url in location

https://github.com/hrgdavor/jscadui/assets/1766297/c074534b-cb22-4490-bc77-dcdc6d434ee3

[hrgdavor]

I think support for remote might not be necessary as worker could/should be able to load such url. I am not 100% on this, need to test.

[hrgdavor]

also better test would be to load: https://3d.hrg.hr/tmp/darvin/jscad/planter.mesh.js as it has no cors headers

our example from github has cors headers and can easily work without remote support with normal fetch.

[hrgdavor]

there is one comment from stackoverflow that makes sense for workers to be also bound by cors.

Service workers/workers are frontend code running at a particular origin and are restricted by the same-origin exactly in the same way as any other frontend code. If you could get around the same-origin policy just be creating a service worker, the same-origin policy would be useless as a security measure.

however there is importScripts too I could for this special case run a worker that has scipt apended to worker code and have worker use main and getParametereDefinitions from global scope ...

The best is probably to generate a simple worker-script dynamically, which will internally call importScripts (), which is not limited by this cross-origin restriction

I may be fighting a losing battle here, but somehow I am stuck with idea that this could be done :D ... and this may be more trouble than it is worth.

[hrgdavor]

I moved call to serve inside buld script as a parameter.

Also I would like to steal your minimal server and move it to my @jsx6/serve package, as I was looking to shed some bloat of live-server. There I would expand it a bit to allow pluggable support for SSE events to trigger reloading as simpler alternative to websockets. This way serve lib package would not bring bloat but would still allow for supporting live-reload type functionality.