My project had a dependency that was on github, so when I installed it I ran
$ composer config repositories.vendor/package vcs https://github.com/vendor/package.git
$ composer require vendor/package
Now, I need to remove that package.
If I just run $ composer remove vendor/package the "repositories" section is still in my composer.json file.
"repositories": {
"type": "vcs",
"url": "https://github.com/vendor/package.git"
},
How can I also remove the "repositories" section from the command line?
You can run composer config --unset repositories.vendor/package to remove the entry from the repositories key.
However, this will still keep the empty repositories key. If you also want to remove that, you will have to use another tool that is able to parse JSON and remove the key yourself.
Related
I work with two repo's; one with source code and one with E2E tests using CucumberJS:
application-repo/
application-e2e/
I would like to run npm run watch in the second repo and wait for changes to files in the first repo; because I want to have my CucumberJS tests run on changes to the source-code. The place I work dictate me not to have the e2e-tests in the same repo, as the source code.
Similar question, but with pm2 instead of npm-watch / watch:
Watch files outside the current directory using pm2
It was a lot easier than I thought, at least when using watch and not npm-watch, but probably both can be used the same way.
Here's my package.json of the second repo:
{
"name": "application-e2e",
"version": "1.0.0",
"description": "",
"main": "index.js",
"scripts": {
"watch":"watch 'echo hello' ../application-repo/", // First repo
(...)
When running npm run watch in the second repo, changes made in the first repo will make it write hello in the terminal of the second repo.
If you want to create you own cocoapods with storyboards, XIBs, resources and with other frameworks such as Alamofire, MBProgressHUD etc.
Easy steps to create Cocoapod from existing xcode project
Create a repository on your git account (Repo name, check README,
choose MIT under license).
Copy the url of your repository.Open terminal and run following command.
git clone copied your repository url
Now copy your Xcode project inside the cloned repository folder on
your Mac. Now run following commands
git add -u to add all files (if not added use: git add filepath/folder)
git commit -m "your custom message"
git push origin master
Create a new release to go to your git repository or run following commands
git tag 1.0.0
git push --tags
First, we need to make sure that you have CocoaPods installed and
ready to use in your Terminal. run the following command:
sudo gem install cocoapods --pre
Creating a Podspec
All Pods have a podspec file. A podspec, as its name suggests,
defines the specifications of the Pod! Now let’s make one, run
following command on terminal
touch PodName.podspec
After adding and modifying your .podspec file. Validate your .podspec
file by hitting following command on terminal
pod lib lint
Once you validate it successfully without errors run following
command to register you and build cocoapod respectively
pod trunk register
pod trunk push PodName.podspec
If all goes well, you will get this on terminal
🚀 PodName (1.0.0) successfully published
📅 February 5th, 02:32
🌎 https://cocoapods.org/pods/PodName
👍 Tell your friends!
Yeah!!!!! congrats you have got your pod link. Use wherever you want to use it.
Here is some useful links . You can follow the same.
https://www.appcoda.com/cocoapods-making-guide/
https://www.raywenderlich.com/5823-how-to-create-a-cocoapod-in-swift
Both use the README.md as the description when you publish. A common practice is to use a single shared file.
But what if I need to have the different Readme and still publish it from a single local repo with no manual editing/replacement
PS
I tried to use "readme": "npm-readme.md" in package.json but it displays a value of this field, not the content of а file
For some reason zavr's answer (using README and README.md) didn't work when I tried it (probably the logic used by NPM has changed). But what did work is putting the GitHub README into .github directory (this is allowed according to their docs), and using the root README.md as the version for NPM along the lines of
<!-- README for NPM; the one for GitHub is in .github directory. -->
<badges>
<a brief description>
Please refer to the [GitHub README](https://github.com/<your repo>#readme) for full documentation.
Luckily, for GitHub .github/README.md seems to take priority over README.md.
Update 2021-02-06: a quick note about best practice. NPM wouldn't let you update the readme without bumping the package version, and in reality you often need to make updates, sometimes minor, to the docs. So I'd recommend to provide full docs in the GitHub readme, but still give a short description of the library on NPM, which in combination with keywords field of package.json will make the package more discoverable. It's also a good idea to include badges in the NPM readme because that will increase the quality score displayed by NPM (see discussion of "branding" score in this article).
Good question mate! I prefer GitHub to NPM for a number of reasons, such as
a) the column on NPM is to narrow and all tables start to scroll
b) there is no padding when images are aligned to left of right
c) the TOC navigation does not work because anchor links are generated differently on GitHub and npm
Therefore I found a solution: add a README file, which will be read by NPM, and keep README.md file which will be read by GitHub. Easy-peasy but no guarantee it will continue to work.
One solution can be to use two readme files and rename them using npm scripting during npm publish.
This can be done as follows.
On source control, we would have the following files:
README.md - This is the default git readme where you would document your source.
npm.README.md - This would be the readme that would be seen on NPM.
Next, we would have the following in package.json (note that some contents are omitted).
{
...
"scripts": {
...
"build": "...",
"use:npmReadme": "mv 'README.md' 'git.README.md' && mv 'npm.README.md' 'README.md'",
"use:gitReadme": "mv 'README.md' 'npm.README.md' && mv 'git.README.md' 'README.md'",
"prepublishOnly": "run-s build use:npmReadme",
"postpublish": "npm run use:gitReadme"
},
"dependencies": {
...
},
"devDependencies": {
...
"npm-run-all": "^4.1.2",
...
}
}
In devDependencies, the npm-run-all package is used. This allows using the run-s command to run specified npm scripts sequentially.
in the scripts section, we have the following scripts:
Scripts to Rename README files
use:npmReadme - This simply backs up the current git specific readme, and then renames npm.README.md to be the default README.md.
use:gitReadme - This simply reverts back to using the git specific readme as the default README.md.
prepublishOnly
This is executed BEFORE the package is prepared and packed, and ONLY on npm publish. (Does not run with npm install).
Here, the solution is built, and then we run use:npmReadme.
postPublish
This is executed AFTER the package is published on npm.
Here, we run use:gitReadme to revert the readme files back to their original state.
More information on prepublishOnly and postPublish can be found here.
keshav.bahadoor's answer inspired me to use similar approach in GitHub workflows.
I'm using it as following:
- uses: actions/checkout#v2
...
- run: mv NPM-README.md README.md
...
- run: npm publish --access public
I'm moving NPM-README.md to README.md only during workflow and not committing.
rest of the workflow yaml file
Note: This is working for GitHub workflows, not makes sense to use in your local.
(the more good one) If we named the npm readme to README.md and the GitHub readme to readme.md. Then we can add readme.md for the npm ignore .npmignore and add the README.md for gitignore .gitignore.
(the more bad one) Add npm.README.md and git.README.md. Remove the npm. or git. when commiting or publishing the git or npm.
I hope the question is somehow explaining, what I want to do. If not, I'll try to give a more detailed explanation:
I am currently migrating a big project from SVN to Git. In this project, all the depencencies where stored in different folders and where commited to the SVN repo. I already learned, that you should not put the vendors folder in your repo. But how would I than update the depenencies? In another ressource I read, that you should only versioning the composer.lock file. How about the composer.json file?
Here is the strategy, I had in mind:
Excluding the vendor folder in the .gitignore file
Adding composer.json and composer.lock file to the repo
Adding a composer_update.php file to use it in a post-receive hook
When we have to update some dependencies, we have than to do the following:
Updating the composer.json file
Running composer update locally to update the composer.lock file (or the composer_update.php script in your local dev instance)
Pushing the changes to Stash/Bitbuckt/Github, which will than execute the composer_update.php script through the post-receive hook
Would you recommend something like this, or is there a better way to do it? I am sorry, but I am really new to composer.
You are supposed to commit both composer.json and composer.lock, as these two files are essential for Composer operation. I bet you misread on what not to commit - from all the things a run with Composer creates, you ONLY commit the lock file, and nothing else.
Commit both the composer.json and composer.lock file.
To update dependencies while development just run composer update in a terminal.
To update dependencies on production run composer install in a terminal. You may add this command to the post-receive hook.
I recently gain administration of a Github repo, on my developing server we use composer, im trying to do a composer update, in composer.json i have defined the repo as VCS type pointing to my github repo.
I commit and push some changes to the repo, but when i do composer update it says there is nothing to update. Other than the commit and the push, there is something else i need to do in order to allow composer to see there is an update in the code?
Consider your repo is https://github.com/auraphp/Aura.Web .
You do commit and push updating the repo for the changes.
Composer is a tool to manage the dependencies for a project. So say if you are using this package downloaded via composer, like
composer.json
{
"require": {
"aura/web": "2.0.*#beta"
}
}
and
$ php composer.phar update
You will get the latest version. In order for composer to understand it is updated, you need to first add the package in packagist.org . What you need to do is activate the service hook in https://github.com/<user/org>/<repo-name>/settings/hooks .
You can get more information from respective websites
Packagist
Composer
For a quick start read http://www.sitepoint.com/php-dependency-management-with-composer/ , there will be many if you search in google.
You only specify your repo URL and it will automatically scan your composer.json for package info. Keep in mind that repositories have a higher priority over Packagist when installing or updating.
The template used regularly in various projects is as follows:
"repositories": [
{
"type":"package",
"package": {
"name": "package-name",
"version":"master",
"type": "wordpress-plugin",
"source": {
"type": "git",
"url": "https://github.com/package-name.git",
"reference":"master"
}
}
}
],
"require": {
"package-name": "dev-master"
}