I wonder if is possibile to "move" the vendor folder to another location. I mean, I've a structure like this
/
Laravel Project 1
Laravel Project 2
Laravel Project 3
[... others ...]
CDN (For vendor if I can)
Well as you know every project comes with the vendor/ folder. I want to move that folder inside the CDN and "merge" all the requirements for every project in another composer outside the projects folder (inside CDN i guess).
Why this?
Simply because I've notice that vendors folder are nearly the same for every project so if I can combine all the "differences" in one single big vendor folder I can manage all the dependencies in one single location, pretty cool
Is that possible?
TY for any help :) Have a nice day.
In Laravel you can change the folder your applications load the framework and dependencies from bootstrap/autoload.php.
There's a require __DIR__.'/../vendor/autoload.php'; line in it and you can change it to whatever you need.
Thus you can change it to some outside folder, common to all projects.
Related
I create tools/bridges between my app/project and 3rd party integrations (like Mailchimp, Calendly a.o.) many of which have their own vendor folder with files.
A typical integration looks like this:
/tool1/index.php composer.json ...
/tool1/vendor/
/tool1/mycode/
/tool2/index.php composer.json ...
/tool2/vendor/
/tool2/mycode/
Same structure for 20+ other tools, many of which have their own vendor folders. Most downloaded or installed from GitHub.
I'm trying to do some maintenance and centralize the vendor folder into the root of the project, instead of calling a vendor folder from each tool. The reason for this is that most use the same packages, such as PSR, Guzzle, league, composer a.o.
It should then look like this:
/vendor/*
/tool1/index.php composer.json ...
/tool1/mycode/
/tool2/index.php composer.json ...
/tool2/mycode/
My issue is (due to lack of knowledge on the subject) that I'm not sure what to do with the autoload files for each of my tools. Obviously, there's an autoload.php in each vendor folder, specifically for that 1 tool (I presume).
Is this asking for trouble and am I better of keeping each tool separated, including the vendor files, or is it good practise to indeed move it to the root folder and spend some time getting my structure in order. If the latter, please advise how to keep things working properly.
It these are really completely independent tools, keep them separated, with their own discrete dependencies.
Trying to merge multiple composer.json files will take you down into dependency-hell, with different tools requiring incompatible dependencies and not being able to install/update.
And trying to have a single vendor for multiple projects will be a fool's errand, since many tools will use slightly different versions of the same dependencies.
The only reason to move everything to the same composer.json file is that if everything was actually one single project, and you need to guarantee a set of version constraints to keep the application working correctly
I am working with composer and I've recently started a new project which requires it. No big deal since I've downloaded the json file and vendor folder and whatnot in another project.
Except I have to copy the composer files from my original project's directory and paste them into the new one. Is this the correct way to go about using composer or should I have the files contained within a single external location and referenced by each of my projects?
I'm aware that this is slightly off topic but I couldn't find a straight answer elsewhere and would appreciate advise on the matter. Thanks.
What you did is okay. Every project folder should have its own composer files. That way, updates or changes to dependencies are isolated per project.
This could be an advanced topic where you can modify php.ini's include path.
You do not need to copy composer vendor files per project. You can specify 'global' as parameter, which will save vendor projects in a global path.
Then, tweak your php.ini's include_path include that global path's autoload.
require_once("vendor/autoload.php");
Do NOT put a './' prefix as './vendor/... and the file is included from the global repository. This is a per-user configuration and may be allowed on your linux console.
Your project's json file is attached within the project itslef, but the vendor path is from global. Many projects can share the same repository. It may not impact the performance too much, because autoload does its best.
I am new to both Symfony and Angular and I am trying figure out how the pieces will fit together. I want to user Symfony for my back end and web api. I want to use Angular for the front end desktop like experiences.
I am not sure how the folder structure should be. Do I put my angular javascript/typescript files in folders in the root of the Symfony project and utilize their folder structure. Or do i have two bundles in my src folder. One for the back end/website. Another for the front end? Or should the back end be serving twig templates with angular components inserted?
***** Edit *****
#Tobias Xy Correct me if I'm wrong but that would be creating bundle in the src folder and keeping the files in a resources folders in it correct?
Then i see the following at the bottom:
Frontend-Based Applications
Recently, frontend technologies like AngularJS have become pretty
popular for developing frontend web applications that talk to an API.
If you are developing an application like this, you should use the
tools that are recommended by the technology, such as Bower and
GruntJS. You should develop your frontend application separately from
your Symfony backend (even separating the repositories if you want).
So they are saying make two seperate projects and not use a bundle for the front end?
If so how do you host this? On two different sites?
Symfony is a backend framework, so there is no point in adding a bundle containing only frontend files (css, javascript, etc).
See also Web Assets (Symfony Best Practices)
They say there:
Store your assets in the web/ directory.
Update 23.03.2016
Cerad wrote in the comments: "client-side angularjs and reactjs apps have their own build system just like Symfony does".
This is actually a different topic, but the article I linked to above also says something about that:
Recently, frontend technologies like AngularJS have become pretty popular for developing frontend web applications that talk to an API.
If you are developing an application like this, you should use the tools that are recommended by the technology, such as Bower and GruntJS. You should develop your frontend application separately from your Symfony backend (even separating the repositories if you want).
For Angular 2 there might be differences in the front end build system, but the structure should be similar to the one I use for Angular 1.x.
The folder structure I use to place my front end assets in something we could describe as a three level process. Let's just enumerate the three levels here:
Level 1 - The src/AppBundle/Resources/Private folder
Inside this folder, I place any front end assets that need any kind of processing, like transpile, autoprefix, uglify, etc. This will be the case for most JS, SCSS, LESS or HTML files of your choice. You can define the folder structure you prefer.
Level 2 - The src/AppBundle/Resources/Public folder
This will be the folder that'll contain all assets after processing AND any other asset that didn't need processing, usually images, fonts, etc. This will be the folder structure that will literally be copied over to the web/bundles/app folder in Level 3.
Note: This level is indeed redundant and can be skipped with caution. In my case, I kept it to avoid 'accidents' with the way Symfony wants to install assets by default, which will replace your web/bundles/app folder with the contents of this one. This will be the case if you use any other bundle that installs assets this way, like FOSJsRoutingBundle for example.
Level 3 - The web/bundles/app folder
This is the final public destination of your assets, and the path where you'll reference them in your code. It is just a copy of the src/AppBundle/Resources/Public folder from level 2.
Build system
You will need a front end build system to transpile your files and copy them to the respective folders in level 2 and 3. In my case for Angular 1.x I used Gulp with Node. This means you'll have gulpfile.js file, package.json file and node_modules folder in your project. I didn't care, it worked fine. Just remember to not add node_modules folder to your repo.
In production
Unless you really need to rebuild in production for some reason, you can skip level 1, level 2 and gulp related folders and files like node_modules, gulpfile.js, etc.
You could create the client side as the root document and the server side as an alias location, but careful to not overwrite the alias.
Or you could change the host.
Example 1:
[client] www.example.com/<client_root_dir>
[server] www.example.com/api/<server_root_dir>
or Example 2:
[client] www.example.com/<client_root_dir>
[server] api.example.com/<server_root_dir>
I want to start a new repo on a current project I'm working on, the idea is to have a repo with, say 60% of the files in my project as a template so I can quickly clone it if I need to (I guess I could use gitignore to achieve that but maybe there is a better way of doing it).
For example:
- Website 1 contains these files/folders:
index.php
app/
config/
css/
I want index.php and app/ to be in the repo as the code will be exactly the same for all future websites I clone. But I need config/ and css/ to be unique to each website.
So now if I go to Website 2 and clone the repo from website 1 I would get index.php and app/ but nothing else, which means I would have to copy all other files manually, Is the a better way to do this?
The reason being that when I upgrade files in the repo I can quickly pull/fetch them on the other clones without affecting the unique files, if that makes sense.
Maybe there's a simple way of doing this.
Yea,
Copy what you want your new template repo to contain into a new folder structure and then create the new repo from that.
If the files are ignored, then you cannot get git to pull them.
If you are really desperate, you could make a new branch, where you remove the gitignore file (or the corresponding rows), then commit all files and pull them from the other server.
After that, you reverse your commit on webserver 1, or you unfollow css, config files.
On webserver 2 you would need to manually unfollow the css, config files too after the pull.
I would rather copy the files manually.
i'm have worked with laravel 3 in the past and used a project structure where multiple apps could use one installation of the framework. now in laravel 4 i am concered if that is still possible. since the bootstrap/autoload.php file requires the vendor/autoload.php file (and so on...), different apps have to use the same autoload files from within the vendor directory, right? i think this would be a big performance problem because the different apps maybe have different requirements, different models to work with and so on. am i thinking right or is there a chance to use one /vendor/ installation for multiple apps without the need to share the autoload files?
to explain my needs: i would like to run different apps (every app with another domain & home directory) which share one database and some models. but the requirements of every app will be very different.
is there any solution? i tried this since the release but found no practicable way.
Have you tried http://laravel.com/docs/routing#sub-domain-routing?
You could create a route group and assign a filter function to that route group to do specific autoloads?
How about modifying bootstrap/autoload.php and vendor/autoload.php to load autoload stuff per project to some kind of sub-directory structure under vendor/composer/.
Not sure, how to change composer to generate that kind of project specific autoload directories. Maybe it needs changing composer?