refactor(setup): abstract platform deps into json config

[HipsterBrown]

Fixes #4 and follow up to #117

While I originally thought the SBOM format might be a standardize way to solve this, it didn't appear to satisfy my expected requirements. Instead, I looked to the PlatformIO project for inspiration. This lead me to their platform.json manifest file to define platform definitions for integrating with the PlatformIO tooling.

In this PR, I've adapted the platform.json idea into a fairly simple schema with a map of dependencies of various types ("repo", "package", "download") and other fields ("os", "source", "installer"). This should be able to cover the basic requirements for each platform.

TODO:

• create formal JSON Schema definition for validation
• create pico platform.json
• create fontbm platform.json
• create Moddable platform.json (?)
• refactor setup tasks to use platform.json schema
• determine how to fetch schema from Moddable as source of truth

/cc: @phoddie @andycarle

[phoddie]

Thanks for working on this. I'm not very familiar with the PlatformIO manifest. I think I could learn to work with what you show in the two files. A few questions:

• Is this a subset of PlatformIO's manifest or "inspired by" their manifest? Either could be fine, I just want to understand.
• The "refactor setup tasks" task is the implementation to get the bits noted in the manifest
• For "determine how to fetch schema from Moddable as source of truth" – are you thinking something like a directory in the Moddable SDK or something separate?

[HipsterBrown]

@phoddie

Is this a subset of PlatformIO's manifest or "inspired by" their manifest? Either could be fine, I just want to understand.

This is inspired by their manifest. From the PlatformIO documentation, I couldn't tell what their specific prefixes and format translated to in their tooling. This is very focused on the types of dependencies required by Moddable that can be automated by xs-dev.

The "refactor setup tasks" task is the implementation to get the bits noted in the manifest

Yes. I have a rough idea of how to consume the manifest files and run the tasks associated with each dependency. This has some real potential to reduce the amount of overall code since the details are abstracted into general tasks and these manifests.

For "determine how to fetch schema from Moddable as source of truth" – are you thinking something like a directory in the Moddable SDK or something separate?

Yes, I was considering these files could be stored within the Moddable codebase and tied to each release, possibly within the build/devices/<device>/ directories. As part of updating to a new release, xs-dev could verify any changes in the manifests (platform.json) based on the devices that have already been set up in the local environment and prompt the user about updating to match the expectations of the SDK. Along with the versioned releases, this has the potential to support multiple versions of the SDK in a single environment for projects that need to use certain versions until they're ready to update. This came to mind recently when reading the release notes for the April release of the SDK mentioning the work on supporting ESP-IDF v5. This is not an immediate plan to turn xs-dev into a version manager, but it would be possible with the platform.json manifests and versioned releases.

[phoddie]

Thanks for the details. That all makes good sense. The code simplifications for xs-dev – basically moving to something that is more data driven - should make it easier to integrate new platforms and tools.

Putting the platform dependencies manifests in build/devices should work for devices. The devices directory doesn't current have sub-directories for macOS, Windows, Linux, and wasm targets though. I guess these's no harm in adding them though to be consistent for this feature.

[HipsterBrown]

The devices directory doesn't current have sub-directories for macOS, Windows, Linux, and wasm targets though

For wasm, I agree it should be treated like another device target. The OS targets are interesting because they are part of the Moddable SDK install and should use the pre-built tooling by default, so I had not thought about abstracting their setup into manifests yet. But there are still expected dependencies on each OS even for targeting the simulator, so those could still be defined by a platform.json and consumed by xs-dev after cloning the Moddable repo.

As an aside, we haven't updated the Windows setup process to take advantage of the releases yet.

[phoddie]

I see your point.

But there are still expected dependencies on each OS even for targeting the simulator, so those could still be defined by a platform.json and consumed by xs-dev after cloning the Moddable repo.

Maybe these are such special cases (Xcode command line tools) that there's not much point in managing it through to the platform manifest?

[HipsterBrown]

Linux and Windows still have some dependencies, although Linux is still for compiling the tooling when not using pre-built releases I believe. I'm fine keeping the SDK setup separate from the platform manifest scheme for now.