report issues in scripts during build

[macMikey]

I am able to write code that is invalid and build my app without complaint, but as soon as I open the UI stack in LC, I will get script errors.

Example:

repeat for each buttonName in buttonNames
 ...
end repeat

In the above I am missing the keyword item before buttonName

[macMikey]

I'm deep in the weeds on this one, but it's surprisingly straightforward to accomplish...until I dive into writing it... I think we want to have a setting in the app.yml for whether to do this or not, but I'm torn on whether to put it in a build profile or just a regular preference. If it was in a build profile, you could have a test profile with the setting, and a release profile that did not.

[trevordevore]

If you want to report during the build process then I don't think a build profile is the right place to put it. Build profiles are for determining run-time behavior. You want to check scripts at build time.

I think the case could be made that you should never be able to build an app with code that doesn't compile. That being said if you have a large project with lots of scripts then it might take a while. But for the POC I would suggest just adding it to the build process and worrying about a setting later. If anything it would be a parameter passed to the function that builds applications. It doesn't belong in app.yml.

Testing scripts is easy enough - just create a stack in memory that you can assign scripts to in order to test. The plugin that connects LiveCode to Sublime Text does this:

https://github.com/trevordevore/levure/blob/develop/utils/external_editor_server/external_editor_server.livecodescript#L57

It only has to account for script only stacks, but the idea can be abstracted into a function that accepts any script to test. This could be used for any handlers in the build process that adds script only stacks. A function that loops over all objects in a stack file and tests any scripts could then be used from any handler in the build process that adds stack files.

[macMikey]

Right, the SE compiler works similarly to the ST/LC server - but the ST/LC server has never worked reliably for me. It works...it doesn't. The rest of the trick is traversing the app tree to check some or all of the files in the tree. I don't think it's necessary to hit every stack and walk it the way the PB does, since what we're really concerned with are .livecodescript files, that were edited with an external editor, and therefore not already checked by the SE.

I'm not opposed to using a parameter to levurePackageApplication, but since levurePackageApplication takes a build type, that gave me the idea to leverage the app.yml to save me time modifying a number of project settings (#181), since every release follows many test builds, and at least on mobile, test builds are very different from release builds. Example: levurePackageApplication "test" might:

• test compile all the .livecodescript files in the tree

• 181, which includes things like including the remote debugger, not encrypting stacks, firing breakpoints

• be used to tell logger output to answer

levurePackageApplication "release" might

• not test compile
• omit the remote debugger
• encrypt stacks
• fire off a message to airLaunch, which then does all the stuff that needs to be done to stick the build on the website.
• be used to tell logger to put the message in a file, or a table in the db, or upload to the server.

I don't remember what either of us were thinking about with #79, but at the end, there is certainly feedback to provide.