Titanium JIRA Archive
Alloy (ALOY)

[ALOY-1115] CLI command to create a project from an Alloy test case

GitHub Issuen/a
TypeNew Feature
PriorityMedium
StatusResolved
ResolutionFixed
Resolution Date2014-09-22T04:53:26.000+0000
Affected Version/sn/a
Fix Version/sAlloy 1.7.0
ComponentsSamples & Templates, Tooling
Labelsn/a
ReporterTim Statler
AssigneeTim Poulsen
Created2014-08-19T21:18:58.000+0000
Updated2015-06-08T21:39:26.000+0000

Description

In a recent email thread, [~skypanther] had an idea to add an alloy CLI to create a new Alloy project from a given sample, e.g. alloy create_sample basics/simple. Moar: bq. ...The samples are actually installed to the developer’s computer...as is a shell/template app. Such a command could merge the two, putting the resulting files in the developer’s workspace directory. There is also a [doc ticket|TIDOC-1849] to better expose the samples, but this type of tool enhancement would be nice, too.

Comments

  1. Tim Poulsen 2014-09-16

    PR https://github.com/appcelerator/alloy/pull/565 Functional test: 1. Create a new Titanium Classic project ti create --name foo 2. Change to the project's directory cd foo 3. "Alloy-ize" the project, specifying the test app to import by adding the --testapp parameter followed by the directory and name of the test app to import. E.g. alloy new . --testapp ui/tableview 4. Build the project for fun & profit ti build -p ios When testing, be sure to test on OS X and Windows (should work on Linux too). Make sure to do test builds for iOS, Android, and MobileWeb. On Windows, you should use the \ slash alloy new . --testapp ui\tableview though in theory the / should work too. Notes: * None of the samples that require files outside of the app folder will work without additional steps. For example, you would need to create an i18n folder for the advanced/localization app. Or, you would need to install the native modules used by the advanced/native_modules app. * The "testing" apps (those used internally by Alloy developers) are not installed with the rest of Alloy. So, you cannot create a test app based on any of them.
  2. Tim Statler 2014-09-18

    This is awesome, Tim. My comments: * The workaround for this is [already documented](http://docs.appcelerator.com/titanium/latest/#!/guide/Alloy_Samples-section-37535160_AlloySamples-TestCaseExamples), but if the test app contains a specs folder you usually get runtime errors. Maybe the tool could alert the user to this if the target sample has a specs folder...maybe mention the same workaround? Might be asking too much, I realize. * This is purely a personal preference (so take with grain of salt) but I'd prefer a command line option to the testapp: prefix, e.g. alloy new --testapp ui/tableview. But I'm fine with the current approach.
  3. Tim Poulsen 2014-09-18

    Thanks for the feedback. I should be able to filter out copying the specs folder so that it wouldn't be a problem for users. I initially tried with a --testapp arg but it wasn't working and the prefix was easier for a proof of concept. But I'll see about reworking it to use the argument.
  4. Tim Poulsen 2014-09-19

    PR updated to implement --testapp arg rather than prefix method originally used. Also copying excludes the specs folder. Added a test to the jake test:spec\[new.js\] test script. Functional test -- see my comment above.
  5. Tim Statler 2014-09-19

    Perhaps this is expected, but filtering out the specs/ folder doesn't fix the runtime errors, since apps require in the specs/index.js file, e.g. 
       if (!ENV_PROD) {
   	require('specs/index')($);
   }
    Again, we can/do document this issue for users, but I wasn't sure if the expectation was that the filtering would fix the runtime error, which it doesn't.
  6. Tim Poulsen 2014-09-19

    Ah, good catch. It was not my expectation that this change would catch runtime errors. There are a couple of other ways to handle this besides documenting the issue: * I could add an output message after you create an app with --testapp that reminds developers to remove the require() statement * Or, I could modify the scripts to also copy the testrunner harness files so that the specs would actually run Thoughts?
  7. Tim Statler 2014-09-19

    I vote for copying the harness files, so it works out of the box.
  8. Tim Poulsen 2014-09-19

    I updated the PR to copy both the specs and the necessary testing framework files. This new PR also excludes the _generated folder from the set of files copied. Functional test is the same as above, though if you test with the advanced/form_factor you can test that the specs work -- after using alloy new build and run the app. It should run without errors and the app's unit tests should run.
  9. Feon Sua Xin Miao 2014-09-22

    PR merged.

JSON Source