I am using Composer and I'm on OS X.
It's putting the git clones for required packages in ~/.composer/vendor/.
Some of these libraries are source code I may want to work with, make patches or pull requests, and so having these hidden away in a .folder is a pain.
How can I get Composer to put these somewhere else?
Ideally, I'd like that on a case by case basis, but I could live with them being somewhere more OS X-ish, such as ~/Library/Application\ Support/Composer for example.
It seems like you have discovered the cache. You shouldn't care about it's location or content. That's why it is hidden.
If you run Composer with "--prefer-source", it will clone the repositories needed into the vendor folder of your application. There you can work with them if you feel the need.
Related
I've got a pretty simple repository made up of a frontend folder in which I have a react app, and a backend folder that is mostly empty for now.
Every few minutes, regardless of whether or not I make any changes to any files, some node_modules file will pop up in GitHub desktop showing a difference.
screenshot of my github desktop
Do I need to add node_modules to my .gitignore file?
This didn't happen before, I don't know what happened to trigger this. I add the changes because I assume it's an important node_modules update but then it happens again a few minutes later.
I'd like to understand why this is happening and how I can prevent it from happening as it makes my commit history impossible to read.
Simplest solution would be to gitignore node modules like so...
/node_modules
Unless you have a specific reason to track changes to npm?
It's usually better to install fresh packages via npm install when setting up on a different enviroment/device.
In my composer.json file I like to list all compatible versions of the (example) package x/y as possible in the require section. Typically that would look like "x/y": "8-10". If I execute composer install, composer of course installs the newest available version of x/y which is 10.x and that is fine, almost always. But sometimes I want to install version 8 of x/y just to check that execution of my application is still possible with version 8.
Another scenario is when a client reports a bug and has version 2.10.4 of some example/dependency whereas the newest would be 2.14.2. The example/dependency is not required by my application directly but transitively by x/y. So I just for a moment want to install my whole dependency tree with version 2.10.4 of example/dependency to debug it with that version of the library.
Of course a temporary modification of the composer.json so that it requires these exact versions would work but that approach seems unnatural, complex, and implies the risk of accidentally committing the modified composer.json to version control and thereby creating a huge mess.
I thought about modifying the composer.lock because accidentally committing a modified version of that wouldn't really cause a problem. But is it okay/recommended to modify the composer.lock file for such purposes?
Ideally I would want a command line argument that fixes some library to some version just for one execution of the composer install command without modifying composer.json.
Since install is meant to read from a lockfile, this option wouldn't make sense for the command.
But for update (and if there is no lockfile, install behaves as update), there is the --prefer-lowest flag (docs).
There is also the option to downgrade a specific package without affecting your composer.json file, by running something like:
composer update --with vendor/package:2.0.1
Mind you, any of these options will modify your lockfile, so after testing you would probably need to git restore composer.lock to go back to the original state.
Commiting a lockfile for a project by mistake should be a biggish issue. Since applications are usually built/deployed by reading the lockfile, a lockfile in an inconsistent state could break things in unexpected places.
But warding of commiting and pushing changes by mistake seems to be excessive, IMO. Developers can make changes to any file, and if they commit those "by mistake", things can break all around.
Expecting a basic "I should look what's changed before staging and commiting" seems a very low bar to me.
This may be a stupid question but after a fair bit of googling i and still unsure weather i should be removing the the composer.phar file after installation. Is the files just part of the installation or required to run the application ?
The Composer executable is used to manage your dependencies, which is mostly "update" and "install". The result is an autogenerated autoloader and a complete tree of files from the required packages of the application.
The executable itself is not part of the application and therefore is not needed to run it. For security reasons it should not be present on the live servers unless you really know it has to be there, because it seems like a good idea to not give an attacker some useful tools into their hands.
The proper places to have the executable are your development environment (in order to add new packages and update the old ones) and the deployment server that puts the application onto the live server (otherwise you cannot install the packages that your application runs with).
I know that people tend to create a workflow that simply pushes a branch to production, and a post-transmit hook then runs composer install, but this is dangerous from a reliability standpoint: What if Github has an unexpected downtime and you push to production, unable to download the new packages? In this scenario, the server doing the deployment actually is the production server and so requires a copy of the Composer executable, but I explained that this is no ideal setup.
I am working on a Laravel project and it's working fine. But
Recently I have updated Composer by composer update and Composer updated successfully.
Then I have removed unnecessary packges from the vendor folder. I have also removed paragonie folder from vendor, which is unwanted for me.
This gave me following error.
Fatal error: require(): Failed opening required '/var/www/laravel/vendor/paragonie/random_compat/lib/random.php' (include_path='.:/usr/share/php:/usr/share/pear') in /var/www/laravel/vendor/composer/autoload_real.php on line 54`
I have added this folder and working fine.
Any one can help me to figure out what is purpose of paragonie folder.
Why it is included?
Composer manages every package inside the vendor/ folder. You simply can't remove any folder from vendor/ without breaking something. Don't do this!
If you want to remove packages from your project then edit your composer.json and perform a composer install.
There might be some packages in your vendor folder that are not required from your composer.json. This is because ever package can have it's own requirements. If you delete one of these required packages you break it.
There is generally NO necessity to remove anything from vendor!
Note: composer update does NOT update Composer itself. It updates every package of your project! To update Composer itself use composer self-update.
I really recommend you to read the composer docs or some tutorial on how composer works for a better understanding of composer.
Don't manually edit composer.json, or the file-structure of the vendors folder. The vendors folder contains the dependencies and their dependencies.
The most important part about this is that you should not EVER edit a project dependency within a project. The second you do, you have broken future updates, This is a terrible thing.
If you feel this is not possible because a library needs changes, I'd suggest taking a breath.
Most libraries have some built-in configuration options, or methods of modifying the library. If they don't then maybe contribute some, or fork the library.
You can absolutely make changes to any library that has a permissive license towards source code modifications, that is why open-source code exists, but you need to do this in the right way.
You can possibly improve the code by forking using source control, which will also allow you to submit a pull-request(PR) to the package maintainers.
The benefit of trying this is that IF the package maintainers decide to accept your changes, you will be up-to-date with all of their future updates, even if you do not have time to maintain your changes, someone will probably pick them up and make their changes.
IF your PR is not accepted; I would strongly consider revisiting your initial assumptions so that you can be sure the decisions you are making are the only way, or the most beneficial way forward. Either way; it won't matter, as you can keep your fork as the version you pull from in future and either add it to packagist (only if you are really more people will benefit from it); or telling composer to pull directly from your repository (it does have to be on the internet AFAIK).
If you have to fork, you will need to ensure you can maintain the dependency, and this is accepted within your organisation. If it's you then in future, you can manually update from time-to-time from the original source library; to ensure you still enjoy the benefits of the core library, whilst keeping your changes.
THIS IS THE DIFFERENCE BETWEEN HIGH-SCHOOL CODING AND PROFESSIONAL DEVELOPMENT.
sorry for shouting / exclaiming, but this needs to be put out there more, possibly in 100ft letters somewhere.
Resolving this problem folowing these steps:
go to your project from terminal (CLI)
cd vendor
svn add paragonie
svn commit -m ""
And if another file is missing do the same thing.
For me it works 100%.
Good luck.
Can I create a symlink to the local extension from aonther project folder? I have a common local-server and i need to implement same extension on all local project-installations. I tried to put the symlink, but some times i do not get expected output. I get it only after clearing the cache of that perticular project.
Your scenario is a common one I guess. But as Omar said, linking to the same code base of the extension through several typo3 instances is not a good practice.
But we have the same structure as yours, we realize this through SVN. All of our projects got a SVN repository and common extensions have their own repository. Through svn:externals the extensions are linked into the concrete project. This has the advantage that you can change the extension in the concrete project and after committing all other projects (that do have to update from svn though) contribute from it. I Think this would fit your needs, too.
If I understand your question correctly you have several Typo3 sites on the same server and want to share an extension between them using a symlink. I don't think that is a very great idea because many extensions use tables and every site normally has it's own database so you would have to do a lot of tinkering to get that to work.
Instead you could make all the modifications to the extension files in the typo3conf/ext/extension_name folder and then export the extension to a t3x file (Ext Manager in the Backend). This t3x file can be installed as a extension (Import extension) on all your other sites.
If you extension does not use a database and you are planning to make frequent changes then I guess you should be able to make that work (the symlink). Otherwise I recommend you use the first approach I described.
I have not tried this, but you should be able to install extensions globally in Typo3. What this means is that the given extension is placed inside '(typo3_src/)typo3/ext/' instead of 'typo3conf/ext/', presuming both sites use the same Typo3 Core/Source (and thus typo3_src is a symlink to the location of the core).
You can enable installing global extensions via the Install Tool. Once inside the tool, click on 'All Configuration', then search for allowGlobalInstall. Or put the following line into your localconf.php:
$TYPO3_CONF_VARS['EXT']['allowGlobalInstall'] = '1';
At last, but not least, you need to make sure the 'typo3/ext/' directory is writeable.
Hope this will be to some help. If you have any further questions, let me know :)
As Björn mentioned, I'd sugegst to install them globally. Mind you, updating the source will require to move the extensions accordingly..
As for "expected output": be aware that the code in these folders is cached in various ways (mainly page content and config settings), and hence not always run. This is the reason a change done from "outside" the current installation is likely not to propagate to your output without clearing these caches (as you have observed).
When you actually install an extension via the extension manager, the cache should (if correctly configured) be cleared (interested parties may search for clearCacheOnLoad in class.em_index.php to reveal a clear_cacheCmd('all')). There is a small checkbox, which is normally checked, during the installation process to accomplish this.
Omar's first approach is therefore, as I see it, the more easy way to get "expected output" and less jumbling around with global extensions.