project / manifest management

[phoddie]

The xs-dev tools to manage projects and their manifests helpfully automate what are currently manual operations. In exploring it, I have a few observations to share:

• The list of available modules displayed with xs-dev include is really great.
• Entering xs-dev include http brings up the module picker, which makes sense because the correct name is network/http. It could be helpful if the picker filter was pre-populated with "http" to accelerate the search
• Using xs-dev include network/http twice results in the module being included twice. This is generally safe but definitely results in more confusing manifest.
• xs-dev include fails if the include property in the manifest is a string (as in $MODDABLE/examples/helloworld/manifest.json). mcconfig treats that special case as a single element array.
• xs-dev include fails there is no include property. That is rare, but is allowed.
• Sometimes you want to add an include to a specific platform rather than all targets. That is done using the platforms section of the manifest. It would be cool if xs-dev include network/http --device=pico could do that too.
  • The message output by xs-dev remove network/http is not quite right: "Removing "http" to manifest includes". It should be "from" instead of "to".
• If the name given doesn't exist, xs-dev remove NO_SUCH_MODULE no error is reported, so typing errors will go unnoticed
• xs-dev remove http removes "network/http". That's either a bug or a feature. It might have unintended side-effects, especially if the module named is short like ("h"). Maybe it should fail and output the possible matches, or output the include it did remove, so it can be quickly noticed and fixed.
• xs-dev init foo outputs Run the project using: xs-dev run. That doesn't work without first doing a cd to the new directory.
• Running xs-dev init foo where foo already exists overwrites the files that are there. That could be destructive of changes the developer has made.
• The xs-dev init foo --typescript option is great, and the possibility to have other templates is intriguing. Maybe they should be clones of examples? The default JavaScript project already is helloworld. We could have a hello TypeScript project too, and others as needed. I often want to start from a network example (mqttbasic) and modify from there, so almost any example might be a starting point for init.

[HipsterBrown]

Maybe they should be clones of examples? The default JavaScript project already is helloworld. We could have a hello TypeScript project too, and others as needed. I often want to start from a network example (mqttbasic) and modify from there, so almost any example might be a starting point for init.

I really like this idea. It wouldn't be too difficult to implement either since there's already code that can recursively look through the examples directory. 🤔

[phoddie]

Thanks! The updated behavior of include maybe sets a model for how it can behave when there are multiple matches. That way xs-dev init mytest --http would show all the http examples.

[HipsterBrown]

The fixes in #37 were released in v0.11.1 of xs-dev! 💯