Files

• extension.ts what previously used to be index.ts
• details.ts kind of behaves like vite's vite.config.ts file, where it is a typescript file that is expected to be executed locally to undertsand the 'config' of your system. Results in the production of details.json file that determines the extension menu display information of an extension

Some new ideas

• build script should produce a zip archive that contains the following files: extension.js, details.json (and could optionally have an auxiliary.js file for things like any bundled UI elements)
  • That zip archive will be named with the extension id, e.g. my-extension.zip
  • must then updated both:
    • vm extension loader: should
    • gui extension menu: must be updated to read some file that lists all available extension zips (e.g. extensions.json), and then load the details for each extension from the zip file itself (e.g. from details.json inside the zip)
    • NOTE: This can be implemented ON TOP of the current system, so that we can incrementally update things
• dev script server could do something cool where it uses the DEPLOYED version of the scratch site for the majority of the file serving, which would massively shrink the package size we need to distribute for development. For the files that need to change based on the extension development environment (e.g. extensions.json), the server handles those correctly.
  • NOTE for future: this does require internet access, so we might want a fallback that can use a locally cached version of the site. Also see below about supporting local versions of the scratch packages, which would also solve this problem.

Example deployed file structure

• gui.js
• index.html
• static/
  • extension-bundles/
    • doodlebot.zip
      • extension.js
      • extension.js.map
      • details.json
      • auxiliary.js
      • auziliary.js.map
    • handpose
      • extension.js
      • extension.js.map
      • details.json
      • auxiliary.js
      • auziliary.js.map
  • extensions.json

[
   "doodlebot",
   "handpose"
]

It SHOULD BE possible...

• to co-develop extensions, i.e. we might have a repo that has multiple extensions co-located. The file structure might look like:
• doodlebot-raise-playground-extensions/
  • package.json
  • basic/
    • extension.ts
    • details.ts
  • line-following/
    • extension.ts
    • details.ts
  • conversation/
    • extension.ts
    • details.ts
• to levereage a LOCAL version of the scratch-packages with the dev script, so that we could co-develop some vm-things along with an extension. Might look like:
  • example-extension/
    • package.json
    • extension.ts
    • details.ts
    • scratch-editor/
      • .gitrepo
      • scratch-gui/*
      • scratch-vm/*
  • NOTE: In this case, we should actually leverage the webpack dev-server for the scratch side so that as we make changes to the vm or the gui, things reload
  • NOTE 2: If we end up git subrepo cloning extension repos into the base scratch repo, we might want to be careful about git subrepo cloning the scratch repo back into the extension repo, which would just be a lot of duplicate files (but maybe not the biggest deal)