Dependencies (Modules and packages)
Closed this issue · 6 comments
We have more than a single major topic here (let’s keep them together unless a split becomes necessary).
This discussion is not limited to Ti.Next, we can apply part of the results also for Ti.Current.
Naming
In Ti.Current there’s no concept of packages, and that’s in contrast with the Node.js/iojs/npm/bower/jspm/apt/… ecosystems. We only have modules.
IMHO we should pay a lot of attention on this.
Native vs JS modules
Given #1 and #2, there should be no actual need to have native modules, everything could (should?) be written as JS. Anyway, native modules will be a thing, or at least there will be a native part of modules.
- will the modules be released and published as compiled artifacts?
- how are we going to define the required native metadata?
- will we interoperate with native package managers? (CocoaPod et alii)
Distribution
This one is huge. Npm? GH? Gitt.io?
- will we support packages available on npm? If we do, are going to define the included and excluded files in a special way?
- on Arrow we can see a private ‘npm’ available, are we going to take that road for Ti.Next too?
ES2015 modules
We now have a language level module system. Is Ti.Next going to implement it?
See the related io.js discussion: nodejs/NG#5
Core modules
Titanium is now a monolithic SDK. We are already seeing a deeper layering of things, there’s HAL, TitaniumKit and then Titanium as a whole.
Would it be a good idea to slim Titanium to the minimum (in current terms just the Kroll and the globals) and then have everything else as a versioned (core) module?
See the related io.js discussion: nodejs/NG#9
Distribution
I am a fan of using tiapp.xml to define dependencies and allow a mixing of things like cocoapods, NPM, and so forth as a source. Allow more sources to be added via a plugin arch. This will allow the greatest diversity of dependency types, because their will be many types.
Core modules,
The windows SDK has the concept of the TitaniumKit that is separate (though bundled with) the "core"
I think however separate versioned modules might be a better way to go. This will again make things easier for the community to maintain and assist with.
@yuchi I don't think #1 means there's no need to have native modules. There will always be the need to integrate third party native code, either in the form of source code, or compiled libraries, so the concept of native module should persist. Native modules would probably have a JS facade and should specify how the native part integrates within the app project at build time.
On the other hand I think that the native app project should be much more visible to the developer, and ideally not generated by a build script, as it is in Ti.Current. The native project should provide build hooks and in any case it should allow to be tweaked easily, when needed.
My ultimate vision here is moving to a smaller "core" like Node and then everything is a module. That doesn't mean it's got to act and feel like a current module and some of the complexities of packaging (especially internal modules vs external modules) could be hidden. Node does this. A lot of their "public APIs" are simply node modules that are included as part of the node distro.
I really want to build a very tiny core engine and set of tools and then everything else is layered on top. I think this gives us all the most control. We would need to continue to enhance the packaging pieces but I think this would be pretty easy.
Useful project for using NPM modules in titanium apps https://github.com/KyleRoss/modclean
Closing for obsolescence