Package Development Workflow

This is something which is bothering me as well. What is the preferred approach to share code between projects?

I try to keep packages in a separate repo and add it to my projects via composer, but it is surely not the best approach for package development.

I try to keep packages in a separate repo and add it to my projects via composer, but it is surely not the best approach for package development.

@navneetrai Why? That’s exactly what Composer is for? For pulling in pre-made code packages into your applications!

@leachcreative The approach I take is a mixture of the old Laravel 4 “workbench” approach.

I create a workbench directly in the root of my project that’s ignored in Git, and then develop my packages in a directory under that, i.e. workbench/package-name. I’ll initiate a new Git repository in this directory, and then work on the package in a dummy Laravel app from there.

The reason for this approach is so I don’t have to keep pushing to a remote repository in order to get the latest version when developing, which can quickly become tedious.

I’d be interested in hearing how others develop packages, in case there’s a more streamlined way!

@martinbean Yes.. of course using composer to do that.. But as you mentioned it is a pain to add and test new features to package..

Right now I am updating the package repo.. then run composer update to my website test deployment to update package and check everything is working as expected.

Your approach sounds much faster.

Hi @leachcreative, @navneetrai and @martinbean ,

I for sure agree with martinbean that packages are the way to go if you want to write your code once and use it everywhere.

As to what the best method is....

Over the last 12 months I have been digging in deep on Laravel package development, because I see packages as business assets and invest in them accordingly. That's why I want them to be well tested and documented.

I use a test driven approach (phpunit). Don't let that scare you off if you're not familiar with it. Once you get the hang of it you develop your code faster than without the testing tools. Throughout the year, I have tweaked my workflow and started documenting it.

Like other business processes, the workflow itself has become a strong business asset.

Can you let me know (or anyone else reading this) where you are stuck so I can help you out? Also, feel free to PM me (i.e. via Twitter - see profile).

I actually develop it in a project, then I pull it out.

Having it in the project makes it easier to develop, and write tests.

once you pull it out, just make a separate package and pull it in via composer.

note you can specify a path to the project so it's a symlink which makes it easy to change the package -- inside the project you are working on.

    "repositories": [
    {
            "type": "path",
            "url": "/Users/robrogers/projects/laravel-jsonaware-exception-handler"
    }
    ],

btw, check out the russian doll caching series on laracasts. he creates a package there and goes through the workflow.

You will want to start with a directory in your project root for your packages under development (i.e. 'packages'). Once you release the package, and require it in another project, it will end up in that project's vendor directory. You will need to let the Laravel project you are using for development know where the package resides, by modifying the autoload attribute of the project's composer.json file:

  "autoload": {
    "classmap": [
      "database"
    ],
    "psr-4": {
      "App\\": "app/",
      "MyName\\MyPackage\\": "packages/myname/mypackage/src/"
    }
  },

In this directory scheme, the namespace, and the relative path from the package directory to the project's phpunit executable will be the same, whether the package is in the 'packages' or 'vendor' directory:

./../../../../vendor/bin/phpunit

This makes a testing workflow as mentioned by @sandervanhooft that much easier. The benefit for development and testing is that you don't have to change any paths or namespaces when you push your package to the public space for requiring in other projects.

Hello,

I come in the thread to add question about package dev workflow. Ok for Php classes and Blade views, but what about Javascript ans SCSS and other assets ? How to don't need to publish them after each change ? Because Mix/Webpack/npm only look in application folder, not in package's resources folder. How do you do ?