[TIMOB-20512] Need to be able change version of Alloy that is used with Appc CLI
| GitHub Issue | n/a |
|---|---|
| Type | Improvement |
| Priority | Medium |
| Status | Closed |
| Resolution | Won't Fix |
| Resolution Date | 2016-03-15T16:29:58.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | CLI |
| Labels | n/a |
| Reporter | Brenton House |
| Assignee | Eric Merriman |
| Created | 2016-02-25T21:20:00.000+0000 |
| Updated | 2017-03-23T22:29:43.000+0000 |
Description
{quote}As a developer,
I want to be able to be able to use a different version (or custom build) of Alloy when using the Appcelerator CLI,
So that I can be able to patch urgent issues and critical defects while waiting for a new version of Alloy{quote}.
With the old build system (Titanium or Ti), I could simply run
npm install -g alloy@versionx to get a different or custom build of Alloy used with a build. Now with the new build system (Appcelerator or Appc), A specific version of Alloy is bundled with the Appcelerator Platform and there is not a simple way to change it on all our developer and build machines.
If there is known way of doing this already, please let us know!
{color:#d04437}We have an Enterprise license and this is critical for us right now as we have a memory leak that we need to patch in Alloy and get it into production quickly.{color}
Hello, I have tried to test the issue. This command seems to work " sudo npm install -g alloy@versionx". Could you try it out? I tested with 1.7.16. Thanks.
That will install alloy to the npm default location which works for a regular "ti build" but when doing an "appc ti build", it uses a version of alloy that ships with the Appcelerator Platform in the ~/.appcelerator folder structure (depending on which version).
Yes, I see your point. This seems to be a regression in the platform. Forwarding to engineer's to decide it's future. Thanks.
This is not a regression, as deciding to whether or not install with a -g flag is a developer decision. [~brentonhouse] you can do this. 1. Go to
~/.appcelerator/install/<your current appc version>/package2. *npm install alloy@versionx* That's it. To verify, you can look at package.json in/.appcelerator/install/5.2.1-3/package/node_modules/alloyto see if the correct version was installed.I would not say this is a very robust solution. For one, we now have no control over what version of Alloy is installed by Appc. Every time Appc updates (major or minor), it may or may not be changing the version of Alloy. If this happened on one of our machines, we could be potentially building the app with the memory leak defect in it, without being clearly aware of the situation. Also, for myself, this might be fine, but Alloy has to be patched on every developer's machine, every build machine, etc. and these instructions might be lead to other problems if followed incorrectly. I would recommend building something into the appc cli that allows you to select or install a custom version of Alloy.
Point taken. But we want the most stable version of alloy installed together with appc updates. If there's any patch needed or bugs found on alloy, it is still best to file a JIRA so we can look into it and ensure the stable version goes out, without the need for users to manually select or install a custom version.
I see that ticket has already been assigned to the next sprint so it shouldn't take long. In fact, will appreciate very much if you could include a test case for it, as mentioned in earlier alloy tickets. Thanks for bringing this up.
[~cbarber] this might be an interesting user story to consider for the refactored build process?
Thanks for the suggestion, but we're heading down the road of pulling Alloy into the Titanium SDK. This is slated for Titanium SDK 6. There will be no more standalone Alloy releases once Titanium SDK 6 ships. During this integration, Alloy's tooling will be overhauled. Many bugs and inconsistencies will be fixed and hopefully no new bugs will be introduced. :) Alloy will be able to take advantage of the build state and hook system. This will improve Alloy's performance and expose Alloy to new features that we couldn't add before because it would break backwards compatibility. Trust me, it's going to be awesome.
OK. obviously, I don't know the architecture of the new system but I *really* hope it is still relatively painless to augment alloy features the way it is now. Modifying, building and deploying the current Titanium SDK is a much bigger task than I have time to go through on a regular basis.
I don't see how you use Alloy changing. From a tooling perspective, you'll be able to hook into it and modify things.
Using existing hooks, I can implement *some* of the features but many I cannot unless I can get into other parts of Alloy. Also, I then have a crazy big alloy.jmk based system that patches everything and holds it together with duct tape. :) Right now, I can get rid of a lot of that and just install a fork of Alloy that is synced downstream from Alloy.
The Alloy.jmk will be one of the things getting cut, but don't worry, you'll be able to do whatever you want with the hook system.
[~brentonhouse] as a workaround you can create a global or project [Titanium CLI](http://docs.appcelerator.com/platform/latest/#!/guide/Titanium_CLI_Plugins-section-37549163_TitaniumCLIPlugins-FunctionandEventHooks) hook where all you do is:
delete process.env.ALLOY_PATH;Thanks [~fokkezb]!! I will try that!
How to https://gist.github.com/falkolab/da74a5fab2a7226090e357ab68426bf6
Excellent [~falko] - will tweet.
Closing ticket as Won't Fix with reference to the above comments.