开发环境

安装Composer

您很有可能已经安装了Composer。但是，如果您尚未安装Composer，启动和运行的最快方法是复制Composer.下载页面上提供的脚本。通过将提供的脚本复制并粘贴到您的命令行中，将会下载、运行并再次删除安装程序。您可以通过运行composer --version验证安装是否成功。要将Composer更新到最新版本，请运行composer self-update。

包装骨架

要开始开发软件包，首先要创建一个空目录。没有必要将包嵌套在现有的Laravel项目中，我强烈建议将您的包与您的(Laravel)项目分开，以便能够轻松区分它们。

就我个人而言，我的套餐存放在~/Packages/中，我的Laravel应用存放在~/WebSites/中。

Composer.json

在扩展包的根目录下，首先使用以下最小配置创建一个composer.json文件(如下所示)。当然，请将所有详细信息替换为你自己的。

重要的是，必须始终如一地命名扩展包。 通常的惯例是使用 GitHub / Gitlab / Bitbucket等用户名后跟一个正斜杠(“ / ”) ，然后使用扩展包名字的kebab case形式。

下面突出显示了一个composer.json示例 。

{
  "name": "johndoe/blogpackage",
  "description": "A demo package",
  "type": "library",
  "license": "MIT",
  "authors": [
    {
      "name": "John Doe",
      "email": "john@doe.com"
    }
  ],
  "require": {}
}

或者，你可以通过在空扩展包目录中运行composer init 来创建 composer.json 文件。

如果你计划发布扩展包，选择合适的扩展包类型(在我们的例子中是“库”)和许可证(例如“ MIT”)是很重要的。 在 ChooseALicense.com了解更多关于开源许可证。

设置命名空间

如果我们想使用传统约定的 src/ 目录来存储我们的代码，那么在创建autoloader (vendor/autoload.php)时，我们需要告诉 Composer 将扩展的名称空间映射到特定的目录。

我们可以在 composer.json 文件中的“ psr-4” autoload键下注册我们的名称空间，如下所示(将名称空间替换为您自己的名称空间) :

{
  ...,

  "require": {},

  "autoload": {
    "psr-4": {
      "JohnDoe\\BlogPackage\\": "src"
    }
  }
}

Psr-4自动加载

现在，你可能想知道为什么我们需要一个“psr-4”键。 Psr 代表 PHP Standards Recommendations，它是由 PHP Framework Interoperability Group (PHP-FIG)提出的标准建议。 这个由20名成员组成的小组，代表了 PHP 社区的一个横截面，提出了一系列 PSR。

在这个列表中，PSR-4代表了一个关于从文件路径自动加载类的建议，它取代了当时流行的 PSR-0自动加载标准。

Psr-0和 PSR-4之间的主要区别在于 PSR-4允许将基本目录映射到某个名称空间，从而允许更短的名称空间。 我认为 StackOverflow 上的这个评论清楚地描述了 PSR-0 和 PSR-4是如何工作的。

PSR-0

"autoload": {
    "psr-0": {
        "Book\\": "src/",
        "Vehicle\\": "src/"
    }
}

• 在 src/Book/History/UnitedStates.php 查找 Book\History\UnitedStates

• 在 src/Vehicle/Air/Wings/Airplane.php 查找Vehicle\Air\Wings\Airplane

PSR-4

"autoload": {
    "psr-4": {
        "Book\\": "src/",
        "Vehicle\\": "src/"
    }
}

• 在 src/History/UnitedStates.php查找Book\History\UnitedStates

• 在 src/Air/Wings/Airplane.php查找Vehicle\Air\Wings\Airplane

在本地导入扩展包

为了帮助开发，你可以在本地 Laravel 项目中引入一个本地扩展包。

如果你有一个本地的 Laravel 项目，可以通过在 Laravel 应用程序的composer.json 文件中定义一个定制的所谓的“仓库” ，在本地引入扩展包。

在 Laravel 应用程序的 composer.json 文件的“scripts”部分下面添加以下“ repositories”键(用扩展包所在的目录替换“url”):

{
  "scripts": { ... },

  "repositories": [
    {
      "type": "path",
      "url": "../../packages/blogpackage"
    }
  ]
}

现在，你可以在 Laravel 应用程序中使用选择的扩展包命名空间来引入本地扩展包。 按照我们的例子，这将是:

composer require johndoe/blogpackage

重要提示: 每当对包的 composer.json 文件或其注册的任何提供程序进行更改时，都需要在 Laravel 应用程序中执行composer update。

Orchestra Testbench

我们现在有一个 composer.json 文件和一个空的 src / 目录。 但是，我们不能访问由 Illuminate 组件提供的任何 Laravel 特定功能。

要在我们的扩展包中使用这些组件，我们需要 Orchestra Testbench。 注意，每个版本的 Laravel 框架都有一个相应的 Orchestra Testbench 版本。 在这篇文章中，我假设我们正在为 Laravel 6.0开发一个扩展包，这是写这篇文章时的最新版本。

composer require --dev "orchestra/testbench=^4.0"

现在我们已经安装了 Orchestra Testbench 扩展包，我们将在包的 vendor 目录中找到一个 orchestra 文件夹。 在这个文件夹中，你会看到一个 laravel 文件夹，其中包含了 Illuminate helpers 和一个 testbench-core 文件夹，在这个文件夹中，你会看到一个名为 laravel 的文件夹，其中有一个 Laravel 项目的完整目录结构。 这允许我们使用 Laravel helpers，它涉及与项目目录结构的交互(例如与文件操作相关的交互)。

在每次测试之前，都会创建一个包含完全启动(测试)应用程序的测试环境。 如果我们在测试中使用 Orchestra TestBench 的基本 TestCase，那么由 Orchestra\Testbench\Concerns 名称空间中的 CreatesApplication trait 提供的方法将负责创建这个测试应用程序。 如果我们查看其中一个方法， getBasePath() ，我们会看到它直接指向 Orchestra Testbench 附带的 laravel 文件夹。

// 'vendor/orchestra/testbench-core/src/Concerns/CreatesApplication.php'
/**
 * Get base path.
 *
 * @return string
 */
protected function getBasePath()
{
    return __DIR__.'/../../laravel';
}

本译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

原文地址：https://learnku.com/docs/laravel-package...

译文地址：https://learnku.com/docs/laravel-package...