[TIMOB-27255] Titanium CLI plugin deprecation notices
GitHub Issue | n/a |
---|---|
Type | Story |
Priority | None |
Status | Open |
Resolution | Unresolved |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | n/a |
Labels | cb-tooling |
Reporter | Chris Barber |
Assignee | Chris Barber |
Created | 2019-07-18T16:52:24.000+0000 |
Updated | 2020-02-10T21:37:32.000+0000 |
Description
There are 2 major Titanium CLI <=5.x plugin related deprecations coming up with the release of the next Titanium CLI, namely version 6.0.
1. Titanium CLI 6 will drop support for all Titanium CLI plugins that are executed for any command other than
"ti build"
(or "appc run"
). That means that any plugin that was loaded for a non-build command, such as "create"/"new", will no longer be loaded in Titanium CLI 6.
* Hooks that will only fire when performing a build
** cli:command-loaded
** cli:go
** cli:post-execute
** cli:post-validate
** cli:pre-execute
** cli:pre-validate
** help:header
* Hooks that will no longer be called
** clean.config
** clean.post
** clean.pre
** create.config
** create.finalize
** create.post
** create.pre
All other build.*
hooks will continue to fire including Alloy, Hyperloop, Liveview, Ti.shadow, etc.
2. Titanium CLI 7 will drop support for all Titanium CLI plugins including "build" related commands.
New Titanium CLI 6 Plugin System
The new Titanium CLI 6 will support plugins in the form of Appc Daemon (appcd) plugins. While the daemon's plugin system exists as well as the underlying hook mechanism, the hook registration system (DAEMON-90) does not exist yet. Once the hook system is implemented in the appcd plugin system, then Titanium CLI <=5.x plugins withclean.*
and create.*
hooks will need to be ported to the new format. Porting is not trivial, but it's hours, not days, of work.
Appcd plugins also have limitations compared to Titanium CLI <=5.x plugins. While pre and post hooks are possible, modifying function hook arguments, the actual hooked function, and the result are not. Furthermore, appcd plugins must be async aware and maintain their own state.
Currently, there are no known plugins that use the clean.*
hooks, however we have several new project templates that use the create.*
hooks. Those project templates will need to be updated.
clean.post
is used in the alloy [deepclean hook](https://github.com/appcelerator/alloy/blob/c63914c87610bcd1bc0e8be3426b160783a0991e/hooks/deepclean.js#L39-L41) that _every_ alloy project will use, as well as in the [windows sdk](https://github.com/appcelerator/titanium_mobile_windows/blob/c58b5b6efcfc75ab69914987e38f6bab50c6a2e0/cli/hooks/clean.js#L21-L31) (maybe this one could be migrated to be a _clean.js file though as I think Chris W added support for that) As for community plugins from a quick search (limited to plugins that are available on GitHub and area not archived by the owner)clean.config
- [tiapp-composer](https://github.com/caffeinalab/tiapp-composer)clean.post
- Most repos seem to be archived, and lots of noise from apps with alloy hooksclean.pre
- Could not find anycreate.*
- Only our reposOne thing to note is that it is probably a very small percentage of teams that are allowed to open-source their code and put it out on GitHub. We probably want to do our due diligence in reaching out to developers and customers to see what they are using as well. Is there a technical reason the new Daemon system supports less hooks than the existing Titanium system?
[~bhouse] The Titanium CLI.next relies on the Appc Daemon where all of the Titanium CLI logic runs in a plugin that is executed in a long running subprocess. Because of that, arbitrary JavaScript "plugin" files are not loaded and I'm not entirely convinced that's even a good idea. Furthermore, Titanium CLI plugins can "hook" into two types of hooks: event and function hooks. Event hooks just fire a callback that an event has occurred such as "build.pre.compile". However, function hooks wrap a function and allow a plugin to modify the arguments going into the function, the function itself, and the return value. The daemon promotes the idea of plugins being decoupled and thus the communicate through a central dispatch system where all payloads must be serializable (via
JSON.stringify()
). Certain data types such as class instances or contexts cannot be serialized without data loss. Even then, things likeError
would have to be reconstructed forinstanceof
to work. As an example of how much pain this is, go look at [vm2](https://www.npmjs.com/package/vm2). The simplest of simple things are [impossible](https://github.com/patriksimek/vm2/issues/62). Unless we add support for one-time loaded scripts, plugins will need to be daemon plugins that abide by the lifecycle and limitations of the daemon.