fully type checked example

[trusktr]

…hirdparty, use three instead of @three so that TS automatically picks up the types from @types/three, etc

[sketchpunk]

Interesting stuff. My notes on the changes you've made.

1. Not deleting the custom version of 3JS that I'm using that's in thirdparty. That is a modified version of the library that fixes two issues. First, the library doesn't support using "compute" shaders, so adding a lil hack allows me access to gl buffer references so I can then use transformfeedback to perform compute shader like things. 2nd reason is they made a change to RawShaders that broke many of my shaders across several repos & even prof stuff. With some effort I convince the powers that be to revert the change and make it opt in, not a default setting because raw shaders should be as expected, raw & unmodified by the system by default, but it wasn't a priority at the time to get that fixed right away.

2. Using vite to setup import alias is cool. Thinking about it, an interesting direction is to try using a front-end way to handle import maps. In many of my libs for supporting github page I handle it on the front end to change how things works between dev & pages. Taking this idea, it would be better to setup different import-map files for different development scenarios. A default one would use the 3JS library coming from npm & another from my custom 3js library. This supports my idea of each page being self-contained app that I can alter depending on my needs for that particular problem I'm working on.

Examples of how I handle it on the front end.
https://github.com/sketchpunklabs/autoskinning/blob/main/import-map.js
https://github.com/sketchpunklabs/autoskinning/blob/main/prototypes/000_tf_pbo.html#L3

3. 007_3js_skel_new/index.html, While this setup is nice & probably a good way to handle creating the examples repo I had planned on making when the library is back into demo showing shape with github pages for viewing. For development, its more cumbersome with how I work having extra parts for my single app idea. Many of the "extra" files I have around looks like 000_someProblem_BAK, 000_someProblem_v1, 000_someProblem_v2, etc. Stuff I dont want to commit but want to have around locally to quickly reference when I'm working on newer attempts at the problem. Ideally, if I loose them or they get deleted, no big deal.

Feel like there is a misunderstanding about the prototypes folder. Its not really meant for the end user as an example of how to use the library. Its more a place with no rules that i can just hammer away at a problem looking for a solution. Type checking isn't important there because I'd like to break the rules or ignore the types that are set when it makes sense in that frame of the prototype. When it comes to demo time, some of the prototypes will be elevated to examples & fixed up & commented for the general audience. Ideally broken out by renderer, so examples/threejs, examples/babylonjs, examples/fungi, etc, etc. Some examples will be repeated to show off working in each respected renderer.

If you want to make your own prototype or example folder setup with types, you can make a lum_proto or something along those lines without worries on stepping on each others toes. That folder can exist on your personal branch and something ignore when creating PR requests to keep things a bit clean.

4. That tsconfig change for include. Not not 100% sure but I remember setting that up as a starting point for the library build process. Any file in src that is not imported in some fashion is ignored and those that exist in a form of import tree gets built into the library. So if I remove/comment out any import in the index file, those files and subfiles shouldn't get built in the library. My concern is that "./prototypes/**/*.js" might automatically include all js files in prototype into the build process. If it does, that can't be set that way. I need the library to be able to be built into an ES library to use in various future ideas.