在创建这个问题时，Stackoverflow已经说过这是我在问的一个主观问题。但是，我认为这是许多入门(包(开发人员在某个时候问自己的问题。
我现在有几年的Laravel经验。我已经到了想要创建一个基于 Laravel的软件包的地步。我做了一些研究，你会发现那里的大量信息已经很旧了，已经过时了。
关于这个主题，我有一个而是几个问题：
- 哪里是一个好的起点？我似乎找不到我应该从哪里开始。我已经阅读了文档，老实说，我仍然在这里一无所知。
- 是否建议先将包创建为普通项目，然后再从中创建包？
- 包应该在哪里开发？您的工作空间是什么？一个常规的拉拉维尔项目？我读过
workbench不再了吗？ - 您是否遵循了一些推荐的教程并发现有用？
我真诚地希望这个问题得到一些好的答案，因为目前的搜索结果不是它们应该的样子。当然不是像拉拉维尔这样的美丽框架。
您需要知道的一切都在文档中，因为它应该是。
除此之外：将包主要视为作曲家包。您不仅在/仅限于Laravel软件包的开发路径，而且实际上是Composer的开发路径，因为它是控制自动加载这些软件包的路径。如果包碰巧包括服务提供商、立面、刀片视图等，那么它就变成了一个集成了Laravel的包。这与移除工作台的原因一致：拥有一个PHP范围的解决方案。
一个好的起点是现有项目，理想情况下，有一组好的包用例。至少在应用程序的开发过程中，可以甚至应该将哪些内容分离到包/库中是很清楚的。作为替代方案，创建一个新的 laravel 项目并围绕包构建定义明确的用例。
以下是开发包的一种可能方法(如SO所述，这是一个主观问题(，它允许"项目内"开发和以后安装作曲家。
免责声明：我没有遵循任何教程，也没有专门搜索它们，因为作曲家和 Laravel 的文档提供了所需的一切。我刚刚查看了vendor文件夹中的其他Composer软件包，这使我相信这是一种有效的方法。以下解决方案甚至不绑定到 Laravel——我在开发 Zend Framework 模块时使用相同的方法。
注意：如果要将软件包发布到pagast上，请检查软件包的命名空间是否未被采用。
设置文件夹结构，该结构可在项目根目录中的lib或packages文件夹中的其他编辑器包中找到。
lib/
my-namespace/
my-package/
config/
src/
Facades/
MyPackage.php
Support/
helpers.php
MyPackageServiceProvider.php
...
将包的src文件夹(以及要自动加载的其他文件(添加到 composer.json 的 laravel 项目的自动加载配置中。(有关可用选项，请参阅作曲家的文档(
"autoload": {
"files": [
"lib/my-namespace/my-package/src/Support/helpers.php"
],
"psr-4": {
"MyNamespace''": "lib/my-namespace/my-package/src/"
}
},
注意：my-namespace文件夹在其自己的存储库中进行版本控制。因此，lib 文件夹可以在项目级别被 git 忽略。
将服务提供商和外观添加到 Laravel 的应用程序配置中，如文档中所述。
按照文档中的描述和其他Laravel软件包中的描述开发和使用该软件包。
每次应用程序忽略包/库中最近所做的更改时，composer dumpautoload运行。
如果一个软件包是公开可用的(例如 github/packagist(，它应该包含最少的通常预期的软件工件，理想情况下遵循语义版本控制。在文件夹内容中大致描述：
docs/
tests/
composer.json
LICENSE
readme.md
注意：我倾向于在一开始就在一个包/库的根目录中添加一个 composer.json 文件。它迫使我清楚地了解这个包提供什么和不提供什么。
要发布包/将其与项目分离，请将相关的自动加载部件从项目的composer.json移动到库的并调整路径。然后将项目发布到packagist/own Toran代理。需要带有--prefer-source的包 - 这样就可以在使用时开发包，即使在多个不同的项目中也是如此。