NotionCommotion Posted May 26, 2018 Share Posted May 26, 2018 Kinda of adding this post to try the new IP.Board. So far, so good! While I've used other people's composer packages before, I've never built my own until recently. Actually, easier than I expected, and it got me thinking I've should have done so earlier. Should one typically write code assuming it will be a composer package regardless of whether hosted by packagist.org? Also, If I am in development mode, I do not wish to host it on packageist, and am doing so as follows. Is this what I should be doing? Package: { "name": "my-vendor-name/my-package-name", "version": "0.0.1", "description": "bla bla.", "type": "project", "minimum-stability": "dev", "require": { "php": ">=7.0" }, "require-dev": {}, "autoload": { "psr-4": { "MyVendorName\\MyPackageName\\": "src/", "MyVendorName\\MyPackageName\\Tests\\": "tests/" } } } App { "require": { "MyVendorName//MyPackageName": "^0.0.1" }, "repositories": [ { "type": "path", "url": "../myLocalRepository/VendorName/*" } ] } Lastly, if my app is a git repository but I have git ignoring the vendor directory, any issues in making vendor/my-vendor-name/my-package-name an independent git repository? Quote Link to comment Share on other sites More sharing options...
NotionCommotion Posted May 26, 2018 Author Share Posted May 26, 2018 I've since slightly changed my thinking, and will only do as showed in my previous post if the classes are general purpose and not related to my domain. For those related to my domain, I will still include MyVendorName and come up with some package name (I read one blog which recommends "Domain" as the package name but I will probably not do so), and locate them in /src. Quote Link to comment Share on other sites More sharing options...
kicken Posted May 26, 2018 Share Posted May 26, 2018 If you have parts of your project that might be useful in other projects as a library, then it may be worth separating them out to their own repository and composer package. Otherwise, just keep them as part of your application project. Any project with a composer.json file could be considered a composer package. Typically packages are libraries but some are projects designed to be used with the composer create-project command. You might do this for example if you had an application that you wanted to be able to easily setup in multiple places. If you don't want your projects public on packagist though, you'll need to setup your own composer repository before you can use the create-project command. I generally will try and separate out what might be good libraries if possible. For top level applications though I usually don't bother with trying to create a proper composer package, create-project isn't that useful really. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.