{
	"id": "97340",
	"key": "ALOY-86",
	"fields": {
		"issuetype": {
			"id": "7",
			"description": "gh.issue.story.desc",
			"name": "Story",
			"subtask": false
		},
		"project": {
			"id": "11113",
			"key": "ALOY",
			"name": "Alloy",
			"projectCategory": {
				"id": "10400",
				"description": "Tools for developing applications",
				"name": "Tooling"
			}
		},
		"fixVersions": [
			{
				"id": "17748",
				"name": "alloy 1.7.35",
				"archived": false,
				"released": true,
				"releaseDate": "2016-02-29"
			},
			{
				"id": "17974",
				"name": "alloy 1.8.0",
				"archived": false,
				"released": true,
				"releaseDate": "2016-03-16"
			}
		],
		"resolution": {
			"id": "1",
			"description": "A fix for this issue is checked into the tree and tested.",
			"name": "Fixed"
		},
		"resolutiondate": "2016-03-11T19:57:32.000+0000",
		"created": "2012-07-16T08:21:55.000+0000",
		"priority": {
			"name": "Medium",
			"id": "3"
		},
		"labels": [],
		"versions": [],
		"issuelinks": [
			{
				"id": "18888",
				"type": {
					"id": "10020",
					"name": "Depends",
					"inward": "is dependent of",
					"outward": "depends on"
				},
				"outwardIssue": {
					"id": "93996",
					"key": "ALOY-79",
					"fields": {
						"summary": "Widgets need to bundle assets and libraries",
						"status": {
							"description": "A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.",
							"name": "Resolved",
							"id": "5",
							"statusCategory": {
								"id": 3,
								"key": "done",
								"colorName": "green",
								"name": "Done"
							}
						},
						"priority": {
							"name": "High",
							"id": "2"
						},
						"issuetype": {
							"id": "1",
							"description": "A problem which impairs or prevents the functions of the product.",
							"name": "Bug",
							"subtask": false
						}
					}
				}
			},
			{
				"id": "50555",
				"type": {
					"id": "10003",
					"name": "Relates",
					"inward": "relates to",
					"outward": "relates to"
				},
				"inwardIssue": {
					"id": "154836",
					"key": "TIMOB-20379",
					"fields": {
						"summary": "Support module distribution via NPM",
						"status": {
							"description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
							"name": "Closed",
							"id": "6",
							"statusCategory": {
								"id": 3,
								"key": "done",
								"colorName": "green",
								"name": "Done"
							}
						},
						"priority": {
							"name": "None",
							"id": "6"
						},
						"issuetype": {
							"id": "7",
							"description": "gh.issue.story.desc",
							"name": "Story",
							"subtask": false
						}
					}
				}
			}
		],
		"assignee": {
			"name": "fokkezb",
			"key": "fokke",
			"displayName": "Fokke Zandbergen",
			"active": true,
			"timeZone": "Europe/Amsterdam"
		},
		"updated": "2016-03-16T22:20:36.000+0000",
		"status": {
			"description": "A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.",
			"name": "Resolved",
			"id": "5",
			"statusCategory": {
				"id": 3,
				"key": "done",
				"colorName": "green",
				"name": "Done"
			}
		},
		"components": [
			{
				"id": "12329",
				"name": "Runtime",
				"description": "Generic bucket for uncategorized runtime issues"
			},
			{
				"id": "12331",
				"name": "Titanium Studio"
			},
			{
				"id": "12326",
				"name": "XML",
				"description": "View XML and parsing"
			}
		],
		"description": "Widgets will need dependency management if we are to build widgets composed of other widgets that may or may not already be in a project. Some things we'll need to do so:\r\n\r\n* A {{dependencies}} key in the manifest. We should probably format this just like the dependencies in nodejs packages to keep it familiar and flexible. \r\n* A dependency manager that needs to be able to:\r\n** check if dependencies are met for a project\r\n** make supported widgets available for installation (think {{npm install PACKAGE}})\r\n** add publicly available dependencies to project when needed, just as npm would.\r\n\r\nThese bullet point will probably require integration with TiStudio. The logic of the dependency manager probably makes most sense in a compiler plugin right now, but this may change as the CLI changes.",
		"attachment": [],
		"flagged": false,
		"summary": "Widget dependency management",
		"creator": {
			"name": "tlukasavage",
			"key": "tlukasavage",
			"displayName": "Tony Lukasavage",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"subtasks": [],
		"reporter": {
			"name": "tlukasavage",
			"key": "tlukasavage",
			"displayName": "Tony Lukasavage",
			"active": true,
			"timeZone": "America/Los_Angeles"
		},
		"environment": null,
		"closedSprints": [
			{
				"id": 596,
				"state": "closed",
				"name": "2016 Sprint 05 Tooling",
				"startDate": "2016-02-27T01:30:53.769Z",
				"endDate": "2016-03-12T01:30:00.000Z",
				"completeDate": "2016-03-14T11:54:10.256Z",
				"originBoardId": 121
			}
		],
		"comment": {
			"comments": [
				{
					"id": "207835",
					"author": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "This is probably post an end of July developer \"pre-release\" issue. ",
					"updateAuthor": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-07-16T14:48:50.000+0000",
					"updated": "2012-07-16T14:48:50.000+0000"
				},
				{
					"id": "208661",
					"author": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "Just like built-in put shipping widgets in alloy - it will take awhile to do a full widget dependency system plus once widgets are downloaded and installed they need to live somewhere a widgets folder at the same level as built-ins seems to make sense.",
					"updateAuthor": {
						"name": "rmcmahon",
						"key": "rmcmahon",
						"displayName": "Russell McMahon",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-07-20T09:08:22.000+0000",
					"updated": "2012-07-20T09:08:22.000+0000"
				},
				{
					"id": "208664",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "Widgets will take up significantly more space than builtins, as builtins are just JS. Widgets will include potentially large amounts of media assets that will unnecessarily bloat the size of the alloy package. \r\n\r\nLet's just make sure we get the wheels turning on the dependency manager because the pre-loaded widgets going into alloy could quickly become scalability issue. \r\n",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2012-07-20T09:20:38.000+0000",
					"updated": "2012-07-20T09:20:38.000+0000"
				},
				{
					"id": "267067",
					"author": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"body": "How is this coming along?\r\n\r\nI think an Titanium-wide (not just Alloy) approach would be best.\r\n\r\nh3. Types of assets to be managed\r\n\r\n* Titanium native modules (like {{ti.storekit}})\r\n* CommonJS modules, including:\r\n** Titanium CommonJS modules (like {{ti.cloud}})\r\n** Alloy sync adapters\r\n** Alloy builtins\r\n** Third-party (momentjs, backbonejs, underscorejs..)\r\n* Alloy widgets\r\n* Alloy JS Makefiles (which would require support for having multiple)\r\n\r\nh3. Local and global installation\r\nLike NPM modules and packaged Titanium native/CommonJS modules, the package manager should allow both global and local (in the project) installation.\r\n\r\nThe {{require}} method can already load global CommonJS modules, so global Alloy sync adapters, Alloy builtins and even third-party CommonJS modules shouldn't be to hard to support. But also Alloy widgets and JS Makefiles need to be loadable from a global ({{~/Library/Application Support/Titanium/widgets}}?) path.\r\n\r\nSince each package at least has its own package-file giving info on the package and its dependencies, they need to be installed in separate directories. This means the Alloy builtins and sync adapters won't be available as {{require('alloy/animation')}} anymore, but would likely be required as {{require('ti.alloy.animation')}}, like a Titanium packaged CommonJS module.\r\n\r\nh3. Dependency files\r\nAlloy already has a dependency list in {{config.json}} and Titanium native/CommonJS modules are listed in {{tiapp.xml}}. I would prefer to have just one dependency list per project and to support both Alloy and Classic projects I would suggest sticking to {{tiapp.xml}}. The Titanium native/CommonJS modules have a {{manifest}} file but the text format might be difficult to use for specifying dependencies with versions and all. The Titanium CommonJS modules have a {{package.json}} file that would be easier to require for all packages to specify their own dependencies.\r\n\r\nh3. Registry\r\nWhen thinking about the online registry, it's clear that the [Marketplace|https://marketplace.appcelerator.com] has to play some role in that. It would need to be restructured in such a way that all discussed types assets can be registered and managed. The registry could be modeled after [NPM|https://npmjs.org/].",
					"updateAuthor": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"created": "2013-08-18T08:28:53.000+0000",
					"updated": "2013-08-18T08:28:53.000+0000"
				},
				{
					"id": "267069",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "As I mentioned on Twitter, I'm reading a lot that sounds like we want everything npm does, but we should use something besides npm. I'm going to do some research, probably talk to isaacs, and see what would be a good fit. We already require nodejs for alloy, titanium CLI, and code processor, and node comes with npm, it seems odd to introduce an entirely other package manager, now forcing developers to have 2, and to deal with all the maintenance issues that come with both. ",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-08-18T13:25:09.000+0000",
					"updated": "2013-08-18T13:25:09.000+0000"
				},
				{
					"id": "267070",
					"author": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"body": "But whatever new or existing package manager we decide to use for Titanium project dependencies, it should be able to handle *all* it's different types of dependencies. If it can't, and you'd still need to manually download native modules or sync adapters, then I rather have a new package manager that does all Titanium project stuff and use NPM for the meta-tools like Alloy.",
					"updateAuthor": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"created": "2013-08-18T13:31:45.000+0000",
					"updated": "2013-08-18T13:31:45.000+0000"
				},
				{
					"id": "267072",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "Handling all dependencies should not be a problem. If npm was used, alloy's custom dependency files like the config.json and widget.json would likely be scrapped for npm's package.json, making the dependencies trivial. Take a look at how [grunt|http://gruntjs.com/] does it with it's dependencies and plugins. It uses simple naming conventions and indicators within the package.json to allow grunt to determine all available plugins on the fly. It's not a tough process, and it's a proven one that utilizes npm almost exactly as we would.\n\nI've emailed [Isaac Schlueter|https://github.com/isaacs] discussing the issue and I gave him some potential ways we'd like to use npm. One is a custom registry so that devs could use the npm client just as they do now, but also have access to the Titanium modules from out registry that would not be injected into the main public npm registry. I'll report back the result of that conversation here, if and when I hear back from him.",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-08-18T14:00:18.000+0000",
					"updated": "2013-08-18T14:00:18.000+0000"
				},
				{
					"id": "267074",
					"author": {
						"name": "mattapperson",
						"key": "mattapperson",
						"displayName": "me@gmail.com",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "What about something like strongloop node. A pass through to npm but with its own repo. This way things like forks of nodejs modules can be maintained and hosted without having to change the name.\r\nAlso we would be able to let users better search for modules, and not polite the nodejs repo with non node items",
					"updateAuthor": {
						"name": "mattapperson",
						"key": "mattapperson",
						"displayName": "me@gmail.com",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-08-18T17:17:37.000+0000",
					"updated": "2013-08-18T17:17:37.000+0000"
				},
				{
					"id": "267099",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "[~mattapperson] your opinion on \"polluting\" the registry _was_ a popular dissent to the idea of using npm. So rather than continue to wonder if it was a bad idea, I talked to Isaac Schlueter, the author of npm, and asked him what he thought of the idea. I won't paste the whole conversation here, but he was 100% behind the idea of using npm for the purposes we are discussing here. To paraphrase him, he knows that npm will always be node-centric, but has big plans to make it the one-stop-shop for all JS, including browser stuff, appc stuff, phonegap plugins, etc...\n\nSooooo... I will work on an initial spec for this in the very near future and will then likely involve the community heavily. Until I do get something out there, if you are really looking forward to contributing, take a look at [grunt|http://gruntjs.com/] as their plugin system is where I will be drawing most of the inspiration. Pay particular attention to how plugins are created, the simple use of a naming convention + package.json keywords for loading on the fly, and the tooling packages they have for creating plugins (grunt-init). This will give you a very good idea of how this will work for Appcelerator as well. ",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-08-19T13:00:38.000+0000",
					"updated": "2013-08-19T13:00:38.000+0000"
				},
				{
					"id": "376512",
					"author": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"body": "PR on master to add support for resolving Alloy widgets as NodeJS modules (after trying existing paths):\r\nhttps://github.com/appcelerator/alloy/pull/755\r\n\r\n[~fmiao] I need to know how to add a test that includes files and folders ({{package.json}}, {{node_modules}}) at the project level.\r\n\r\nI've tested this locally (Mac OS X) and it works great, also with globally installed modules.",
					"updateAuthor": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"created": "2016-02-10T11:11:08.000+0000",
					"updated": "2016-02-10T11:11:08.000+0000"
				},
				{
					"id": "379549",
					"author": {
						"name": "fmiao",
						"key": "fmiao",
						"displayName": "Feon Sua Xin Miao",
						"active": true,
						"timeZone": "America/Vancouver"
					},
					"body": "PR merged.",
					"updateAuthor": {
						"name": "fmiao",
						"key": "fmiao",
						"displayName": "Feon Sua Xin Miao",
						"active": true,
						"timeZone": "America/Vancouver"
					},
					"created": "2016-03-11T19:57:32.000+0000",
					"updated": "2016-03-11T19:57:32.000+0000"
				}
			],
			"maxResults": 12,
			"total": 12,
			"startAt": 0
		}
	}
}