Laravel 5 包开发:从哪里开始?
Laravel 5 package development: where to start?
在创建这个问题时,Whosebug 已经说过这是我要问的一个主观问题。但是,我认为这是许多新手(包)开发人员在某些时候问过自己的问题。
我现在有几年 Laravel 的经验。我已经到了想要创建一个基于 包 的 Laravel 的地步。我做了一些研究,发现大量信息已经过时了。
关于这个问题我有很多问题:
- 哪里是一个好的起点?我似乎找不到我应该从哪里开始。我已经阅读了文档,老实说,我还是一头雾水。
- 是否建议先将包创建为普通项目,然后再从中创建包?
- 包应该在哪里开发?你的工作空间是什么?常规 Laravel 项目?我读过
workbench
没有了吗?
- 是否有一些推荐的教程对您有所帮助?
我真诚地希望这个问题得到一些好的答案,因为目前的搜索结果不是它们应该的。当然不是像 Laravel.
这样漂亮的框架
你需要知道的一切都是in the docs,因为它应该是。
除此之外:将一个包想象成主要是一个 Composer 包。您不仅 on/limited 是 Laravel 包的开发路径,而且实际上是 Composer 的,因为它是控制自动加载这些包的人。如果这个包恰好包含了 Service Providers、Facades、Blade views 等,那么它就变成了一个集成了 Laravel 的包。这符合删除 workbench 的原因:有一个 PHP wide solution.
一个好的起点是一个现有的项目,最好有一组好的包用例。
至少在应用程序的开发过程中,可以清楚什么可以甚至应该分成 packages/libraries。
作为替代方案,创建一个新的 laravel 项目并围绕包构建定义明确的用例。
以下是开发包的一种可能方法(如前所述,这是一个主观问题),它允许 "in-project" 开发和稍后安装作曲家。
免责声明: 我没有遵循任何教程,也没有专门搜索它们,因为 Composer 和 Laravel 的文档提供了所需的一切。我刚刚查看了 vendor
文件夹中的其他 Composer 包,这让我相信这是一种有效的方法。以下解决方案甚至没有绑定到 Laravel - 我在开发 Zend Framework 模块时使用相同的方法。
注意:如果要发布到packagist,请检查包的命名空间是否被占用。
在项目根目录的 lib
或 packages
文件夹中设置一个文件夹结构,就像在其他作曲家包中找到的那样。
lib/
my-namespace/
my-package/
config/
src/
Facades/
MyPackage.php
Support/
helpers.php
MyPackageServiceProvider.php
...
将包的 src
文件夹(以及要自动加载的其他文件)添加到 laravel 项目的 composer.json 自动加载配置中。 (有关可用选项,请参阅 Composer's docs)
"autoload": {
"files": [
"lib/my-namespace/my-package/src/Support/helpers.php"
],
"psr-4": {
"MyNamespace\": "lib/my-namespace/my-package/src/"
}
},
注意: my-namespace
文件夹在其自己的存储库中进行版本控制。因此,可以在项目级别 git-忽略 lib 文件夹。
将服务提供商和门面添加到 Laravel 的应用程序配置中,如文档中所述。
按照文档中的描述和在其他 Laravel 包中看到的那样开发和使用包。
运行 composer dumpautoload
每次应用程序忽略最近在您的 package/library.
中所做的更改
如果要公开提供一个包(例如 github/packagist),它应该至少包含 commonly expected software artefacts and ideally follow semantic versioning。文件夹内容中的粗略描述:
docs/
tests/
composer.json
LICENSE
readme.md
注意: 我倾向于在开头的 package/library 根目录中添加一个 composer.json 文件。它迫使我清楚地了解这个包提供和不提供的内容。
要从项目中发布 package/separate 它,请将相关的自动加载部分从项目的 composer.json
移动到库的 composer.json
并调整路径。然后将项目发布到 packagist/own Toran 代理。
要求包 --prefer-source
- 这样就可以在使用时开发包,即使在多个不同的项目中也是如此。
在创建这个问题时,Whosebug 已经说过这是我要问的一个主观问题。但是,我认为这是许多新手(包)开发人员在某些时候问过自己的问题。
我现在有几年 Laravel 的经验。我已经到了想要创建一个基于 包 的 Laravel 的地步。我做了一些研究,发现大量信息已经过时了。
关于这个问题我有很多问题:
- 哪里是一个好的起点?我似乎找不到我应该从哪里开始。我已经阅读了文档,老实说,我还是一头雾水。
- 是否建议先将包创建为普通项目,然后再从中创建包?
- 包应该在哪里开发?你的工作空间是什么?常规 Laravel 项目?我读过
workbench
没有了吗? - 是否有一些推荐的教程对您有所帮助?
我真诚地希望这个问题得到一些好的答案,因为目前的搜索结果不是它们应该的。当然不是像 Laravel.
这样漂亮的框架你需要知道的一切都是in the docs,因为它应该是。
除此之外:将一个包想象成主要是一个 Composer 包。您不仅 on/limited 是 Laravel 包的开发路径,而且实际上是 Composer 的,因为它是控制自动加载这些包的人。如果这个包恰好包含了 Service Providers、Facades、Blade views 等,那么它就变成了一个集成了 Laravel 的包。这符合删除 workbench 的原因:有一个 PHP wide solution.
一个好的起点是一个现有的项目,最好有一组好的包用例。 至少在应用程序的开发过程中,可以清楚什么可以甚至应该分成 packages/libraries。 作为替代方案,创建一个新的 laravel 项目并围绕包构建定义明确的用例。
以下是开发包的一种可能方法(如前所述,这是一个主观问题),它允许 "in-project" 开发和稍后安装作曲家。
免责声明: 我没有遵循任何教程,也没有专门搜索它们,因为 Composer 和 Laravel 的文档提供了所需的一切。我刚刚查看了 vendor
文件夹中的其他 Composer 包,这让我相信这是一种有效的方法。以下解决方案甚至没有绑定到 Laravel - 我在开发 Zend Framework 模块时使用相同的方法。
注意:如果要发布到packagist,请检查包的命名空间是否被占用。
在项目根目录的 lib
或 packages
文件夹中设置一个文件夹结构,就像在其他作曲家包中找到的那样。
lib/
my-namespace/
my-package/
config/
src/
Facades/
MyPackage.php
Support/
helpers.php
MyPackageServiceProvider.php
...
将包的 src
文件夹(以及要自动加载的其他文件)添加到 laravel 项目的 composer.json 自动加载配置中。 (有关可用选项,请参阅 Composer's docs)
"autoload": {
"files": [
"lib/my-namespace/my-package/src/Support/helpers.php"
],
"psr-4": {
"MyNamespace\": "lib/my-namespace/my-package/src/"
}
},
注意: my-namespace
文件夹在其自己的存储库中进行版本控制。因此,可以在项目级别 git-忽略 lib 文件夹。
将服务提供商和门面添加到 Laravel 的应用程序配置中,如文档中所述。
按照文档中的描述和在其他 Laravel 包中看到的那样开发和使用包。
运行 composer dumpautoload
每次应用程序忽略最近在您的 package/library.
如果要公开提供一个包(例如 github/packagist),它应该至少包含 commonly expected software artefacts and ideally follow semantic versioning。文件夹内容中的粗略描述:
docs/
tests/
composer.json
LICENSE
readme.md
注意: 我倾向于在开头的 package/library 根目录中添加一个 composer.json 文件。它迫使我清楚地了解这个包提供和不提供的内容。
要从项目中发布 package/separate 它,请将相关的自动加载部分从项目的 composer.json
移动到库的 composer.json
并调整路径。然后将项目发布到 packagist/own Toran 代理。
要求包 --prefer-source
- 这样就可以在使用时开发包,即使在多个不同的项目中也是如此。