Laravel 5包开发:从哪里开始? [英] Laravel 5 package development: where to start?

问题描述

在创建此问题时，Stackoverflow已经说过，这是我要问的一个主观问题.但是，我认为这是许多开始(打包)开发人员在某个时候问自己的问题.

我现在有Laravel几年的经验.我已经到了要创建基于Laravel的 package 的地步.我已经进行了一些研究，发现大量信息已经过时，因此已经过时了.

关于这个问题，我没有一个问题，但有几个问题:

• 一个好的起点在哪里?我似乎找不到应该从哪里开始.我已经阅读了文档，说实话，我仍然在黑暗中.
• 是否建议先创建一个包作为普通项目，然后再使用该包创建一个包?
• 该软件包应在哪里开发?您的工作空间是什么?一个常规的L​​aravel项目?我已经读过workbench了吗?
• 您遵循并推荐过一些推荐的教程吗?

我衷心希望这个问题能得到一些好的答案，因为当前的搜索结果不是应该的.当然不是像Laravel这样的漂亮框架.

解决方案

需要要知道的一切都是在文档中，应该如此.

除此之外:认为一个软件包主要是Composer软件包.您不仅在/受限于Laravel软件包的开发路径，而且实际上是Composer的开发路径，因为它是自动加载这些代码的控制者.如果该软件包恰好包含服务提供商，外观，刀片视图等，则它已成为具有Laravel集成的软件包.这与删除工作台的原因是一致的:具有 PHP广泛的解决方案.

一个良好的起点是一个现有项目，理想情况下，该软件包应具有一组良好的用例. 至少在应用程序的开发过程中，可以清楚地知道哪些可以甚至应该分成软件包/库. 作为替代方案，创建一个新的laravel项目并围绕该软件包构建定义明确的用例.

以下是开发软件包的一种可能方式(如SO所述，这是一个主观问题)，该软件包允许项目内"开发和以后的作曲家安装.

免责声明:因为Composer和Laravel的文档提供了所需的一切，所以我没有遵循任何教程，也没有专门搜索它们.我只是看了vendor文件夹中的其他Composer软件包，这使我相信这是一种有效的方法.以下解决方案甚至不与Laravel绑定-开发Zend Framework模块时，我使用相同的方法.

注意:如果您要在Packagist上发布软件包的名称空间，请检查该软件包的命名空间.

在项目根目录的lib或packages文件夹中的其他Composer软件包中找到文件夹结构.

lib/
    my-namespace/
        my-package/
            config/
            src/
                Facades/
                    MyPackage.php
                Support/
                    helpers.php
                MyPackageServiceProvider.php
            ...

将软件包的src文件夹(以及其他要自动加载的文件)添加到laravel项目的composer.json的自动加载配置中. (有关可用选项，请参见作曲家的文档)

"autoload": {
    "files": [
        "lib/my-namespace/my-package/src/Support/helpers.php"
    ],
    "psr-4": {
        "MyNamespace\\": "lib/my-namespace/my-package/src/"
    }
},

注意:my-namespace文件夹在其自己的存储库中受版本控制.因此，可以在项目级别忽略lib文件夹.

按照文档中所述，将服务提供商和外观添加到Laravel的应用程序配置中.

按照文档中的说明开发和使用该软件包，并在其他Laravel软件包中看到.

每次应用程序忽略包/库中最近进行的更改时，运行composer dumpautoload.

如果要公开提供软件包(例如github/packagist)，则应至少包含预期的软件伪像，并且最好遵循语义版本控制.文件夹内容中大致描述:

docs/
tests/
composer.json
LICENSE
readme.md

注意:我倾向于在一开始就在包/库的根目录中添加一个composer.json文件.它迫使我对这个软件包提供和不提供的内容保持清晰的认识.

要发布软件包/将其与项目分开，请将相关的自动加载部件从项目移至库的composer.json，并调整路径.然后将项目发布给包装专家/自己的Toran代理. 使用--prefer-source要求该软件包-这样，即使在多个不同的项目中，也可以在使用时开发该软件包.

Whilst creating this question, Stackoverflow already said this is a subjective question I'm asking. However, I think this is a question many starting (package) developers asked themselves at some point.

I have a couple of years of experience with Laravel now. And I've come to a point where I want to create a Laravel based package. I've done some research and a ton of information you find out there is already old and so outdated.

I have not one but several questions on this subject:

• Where is a good starting point? I can't seem to find where I should start. I've read the docs and honestly I'm still in the dark here.
• Is it recommended to first create your package as a normal project before creating a package out of it?
• Where should the package be developed in? What's your workspace? A regular Laravel project? I've read workbenchis no more?
• Are there some recommened tutorials you've followed and found helpful?

I sincerly hope this question gets some good answers, because current search results are not what they should be. Certainly not for a beautiful framework like Laravel.

解决方案

Everything you need to know is in the docs, as it should be.

Apart from that: Think of a package to be primarily being a Composer package. You are not only on/limited to the development path of Laravel packages but actually Composer's since it's the one that is in control of autoloading those. If the package happens to include Service Providers, Facades, Blade views etc. then it has become a package with Laravel integration. This is in line with the reason the workbench was removed: to have a PHP wide solution.

A good starting point would be an existing project, ideally with a good set of use cases for the package. At least during development of an application it gets clear what could or even should be separated into packages/libraries. As an alternative create a new laravel project and build well defined use cases around the package.

The following is one possible way to develop packages (as SO mentioned, it's a subjective matter) that allows both "in-project" development and composer installs later on.

Disclaimer: I did not follow any tutorials nor did I specifically search for them since Composer and Laravel's docs provide everything needed. I just had a look at other Composer packages in the vendor folder which leads me to believe it's a valid way. The following solution isn't even bound to Laravel - I use the same approach when developing Zend Framework moduls.

Note: Check that the package's namespace is not taken on packagist if you want to publish it there.

Set up a folder structure as may be found in other composer packages in a lib or packages folder in the project root.

lib/
    my-namespace/
        my-package/
            config/
            src/
                Facades/
                    MyPackage.php
                Support/
                    helpers.php
                MyPackageServiceProvider.php
            ...

Add the package's src folder (and additional files to be autoloaded) to the composer.json's autoload configuration of the laravel project. (See Composer's docs for available options)

"autoload": {
    "files": [
        "lib/my-namespace/my-package/src/Support/helpers.php"
    ],
    "psr-4": {
        "MyNamespace\\": "lib/my-namespace/my-package/src/"
    }
},

Note: The my-namespace folder is version controlled in its own repository. Therefor, the lib folder could be git-ignored on the project level.

Add Service Providers and Facades to Laravel's app configuration as mentioned in the docs.

Develop and use the package as described in the docs and seen in other Laravel packages.

Run composer dumpautoload every time the application ignores recently made changes in your package/library.

If a package is meant to be made availabe publicly (e.g. github/packagist) it should include a minimum of the commonly expected software artefacts and ideally follow semantic versioning. Roughly described in folder contents:

docs/
tests/
composer.json
LICENSE
readme.md

Note: I tend to add a composer.json file in the package/library's root right at the beginning. It forces me to keep a clear idea of what this package provides and does not provide.

To publish the package/separate it from the project move related autoload parts from the project's to the library's composer.json and adapt the paths. Then publish the project to packagist/own Toran proxy. Require the package with --prefer-source - this way it is possible to develop the package while in use, even in multiple different projects.

这篇关于Laravel 5包开发:从哪里开始?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！