Chaki is pulling in strip-comments but not using it, and is instead still using a regexp for stripping comments before parsing app.json. Some versions of sencha/cmd generate an app.json that also contains some inline (// ...) comments that chaki chokes on currently.

Switch to using strip-comments instead of the homebrew regexp and verify that lines commented out with // get stripped before parsing

Deleting a package causes a missing template error:

Unhandled Exception: Exception

Message

Could not find template match for "packageDeleted.tpl", checked paths:

html-templates/packages/jarvus-ext-records-tree/delete/packageDeleted.tpl
html-templates/packages/jarvus-ext-records-tree/packageDeleted.tpl
html-templates/packages/packageDeleted.tpl
html-templates/packageDeleted.tpl

Validate all the source code with a linter such that things like this extraneous semicolon leaking globals vars gets eliminated: https://github.com/JarvusInnovations/chaki/blob/master/chaki.js#L9

All the internal functions at the bottom being assigned to undefined variables need to be fixed too. My preference is to just use normal function declarations for those (e.g. function _internalFunction() {}). There is no benefit here to using function expressions over declarations, but the expressions open up the risk of race conditions because their function bodies don't get hoisted to the top of the script like you're probably expecting. See https://javascriptweblog.wordpress.com/2010/07/06/function-declarations-vs-function-expressions/

When running chaki install on an app, add a target hook into the app's build.xml to have it check for package updates or missing packages before each build

Hello all - just testing this works

when grabbing a repo, chaki should look at all the available remote branches and if a framework and/or version-specific branch is available clone that instead of master

For example, if an app is touch 2.4.1.527, chaki would pick the first branch found of:

• touch/2.4.1.527
• touch/2.4.1
• touch/2.4
• touch/2
• touch
• master

I'm guessing the behavior here is to check the chaki.io api for the package and then download as normal. to the current project, or the --app specified project.

Should we add --save flag to add to project's app.json?

app.json contains a randomly generated GUID that's unique to each app. When making the GET request against chaki.io before grabbing a dependent package, pass a SHA1 hash of the GUID in a header somewhere. Might make sense to put that in the User-Agent header.

We will use this header server-side to identify how many distinct applications have pulled each package and provide popularity statistics.

nodegit was left in package.json and doesn't appear to be needed, and i found that some required packages weren't present. Please audit every library that is required in the app and ensure package.json's dependency list is up to date and have appropriate version restrictions

The package data returned from chaki.io includes each packages sub-dependencies, crawl through all these recursively to build a complete list of packages before cloning

Basically the same thing we do at the app level