现状

由于php官方主流的php-fpm短生命周期存在很多限制，很多高级的用法在无法应用于php程序中。swoole支持常驻内存，应用程序可以使用更多高级的用法。

其中包管理composer的设计就是一个典型的例子。

碎片化

vendor目录必须中均为单个php的文件，java语言中所有的包均为jar，虽然php也提供了phar打包机制，但使用的场景非常有限。c/c++程序采用的是 *.so或*.dll作为一个组件（包）。多个版本可以共存，如：libswoole.so.4.2.13、libswoole.so.4.2.12，应用程序可根据需要链接到不同的版本。

服务管理

composer不支持服务管理功能，实际上普通的php程序也没有服务的概念，全部由php-fpm来是实现服务。而swoole启动的进程本身就是服务，应该自带服务管理的功能。node.js的npm就是一个很好的例子，npm start 就可以启动包内的服务。

SPM

基于上述的原因，我们计划实现一个swoole package manager的程序。来提供更高级的包管理器能力。但由于composer几乎接近php的标准，生态非常完善。因此我们会完全兼容composer。

兼容

• spm将100%兼容composer，基于composer进行二次开发。在保证composer所有功能可用的前提下，增加更多swoole特有的高级功能。可以直接将spm作为composer来使用

• spm将内置于swoole boot二进制包中，无需额外安装，可直接使用

• 在composer.json中的配置，使用composer基础模块来处理

• 在package.json中的配置，使用spm处理

以下文档中提供的配置全部在package.json中

phar 包

spm将提供phar包管理功能的功能，类似于java的jar包，依赖某个组件，如easyswoole或swoft时，可以在命令行中执行

spm include swoft/framework

可以使用-g参数安装到全局目录中，其他工程中会有限查找全局目录中是否有满足版本需求的包

或者修改package.json增加：

"require": {
      "swoft/framework": "^2.2"
    }

这将会下载一个swoft/framework.phar.{$version}的包。如：./vendor/spm/swoft/framework.phar.2.0.3

• spm主要借鉴java的maven进行组织
• composer包可以使用spm build-package直接打包为phar格式的spm包

服务管理

使用spm start [-- <args>]可以启动当前包中的服务。

• spm会根据当前包在package.json中定义的命名空间，在该命名空间中查找main函数，并执行

如：package.json中定义了namespace为Swoft\Framwork，spm将执行Swoft\Framework\main()参数。

参数为一个Args对象。包含了传入的一些参数。

{
    "name" : "swoft/framework",
    "namspace" : "Swoft/Framework",
    "description" : ""
}

namespace Swoft/Framework;

function main(Args $args) {
   //code ...
   $server->start();
}

• 在main函数中抛出异常，可以终止启动
• swoft/framework被引入到其他包时，main函数将变成一个内部函数不会被执行
• 执行main函数前，所有依赖的phar包都会被提前include进来，也可以通过配置，指定某些包在WorkerStart时载入

关闭、重启和重载入：

spm stop
spm reload
spm restart

很棒的项目 如果能把 PHP 的包 打包成对 PHP 解释器无依赖的二进制执行文件 放 Linux 服务器上直接运行 那就更棒了 可以把解释器打包进去

@wujunze java也离不开jvm

记得看到过 node 有个项目 可以把 node 包打包成 不依赖 node 解释器的 二进制文件 他也是把解释器打包进去的 可以参考一下

看懂了,spm就是php-fpm(php-spm) + composer = swoole + composer。这样很好哇更符合行业标准更规范吧

有些项目是前后一起的 有node的 package.json 同名有可能出现冲突呢 😄

@wujunze 那个应该只是把node本身也打包进去了。

@inhere 不如叫 swoole.json ?

panda的建议不错，但是这个不应该是spm做的事，可以单独起一个项目做这件事，spm专注于包管理，其他的包来提供其他的能力，比如说typephp😀

@maryhtf 是把 node 打包进去了 @qxhy123 建议不错 单独起一个项目 职责更加清晰

不是很明白，和composer相比，解决了什么问题。spm 是用来管理启动时和WorkerStart时加载的包吗？

不建议使用 package.json 做为依赖管理的文件名，因为和 npm 的 package.json 例如 laravel 里会使用 npm 管理前端文件，文件名就为 package.json 推荐使用 swoole.json spm.json, spm-swoole.json swoole-package.json spm-package.json

不建议使用 package.json 做为依赖管理的文件名，因为和 npm 的 package.json 例如 laravel 里会使用 npm 管理前端文件，文件名就为 package.json 推荐使用 swoole.json spm.json, spm-swoole.json swoole-package.json spm-package.json

附议，另外如果完全兼容composer，也可以考虑直接使用composer.json

既然完全兼容composer，希望可以直接使用composer.json

Composer本身的scripts字段就能实现服务管理，然后同时存在多个版本的场景是什么？版本管理的目的之一就是根据依赖选择最合适的唯一的版本。

我觉得这个项目的核心没有出来，不用phar继续用文件也能实现同样的事情，版本管理用户也不会使用多版本，想要换成某个版本只需要在composer.json上指定对应的版本即可，启动命令可以通过Composer的scripts完成。

如果不考虑多版本的话完全可以在 composer 里做插件来实现，composer 的插件机制很强大。 例如这种就是通过 composer 通过插件的形式管理和安装 npm 包的 https://github.com/fxpio/foxy yii 3.0 使用的就是这个

直接兼容phar+composer是不是就可以了，这样升级\学习成本就会少很多。至于服务化是swoole独有的

期待早日支持socket.io ，自定义定时任务和兼容rpc，如grpc，thrift等

期待早日支持socket.io ，自定义定时任务和兼容rpc，如grpc，thrift等

这些都是自己封装的啊，swoole哪来这么多精力做这么多事 😄

phar包中 realpath可能会有问题

感觉没有什么用

期待早日支持socket.io ，自定义定时任务和兼容rpc，如grpc，thrift等

这些都是自己封装的啊，swoole哪来这么多精力做这么多事 😄

那也要给出自定义增加进程的方式啊，我添加个addprocess到 serve上，启动就变成3个进程了，基本无法管理进程的，都不知道咋回事，感觉不可靠

npm start 就可以启动包内的服务。

npm start 实际执行的是npm run start，对应package.json中script start后面自定义的命令；并不是npm去启动的服务，依赖其他包提供的web server，比如webpack-dev-server

期待早日支持socket.io ，自定义定时任务和兼容rpc，如grpc，thrift等

这些都是自己封装的啊，swoole哪来这么多精力做这么多事 smile

那也要给出自定义增加进程的方式啊，我添加个addprocess到 serve上，启动就变成3个进程了，基本无法管理进程的，都不知道咋回事，感觉不可靠

文档里面都有，添加自定义进程挂到master下面。socket.io rpc 可以参考https://github.com/lizhichao/one

做成一个 symfony console 工具包就可以了，包管理还需要集中管理的服务器。