I starting with a yarn workspace that has packages that are already named. I'd like to change the name of one of the packages but have not been able to find the necessary procedure for doing this.
Here's the current structure of the file:
{
"name": "gatsby-starter-theme-workspace",
"private": true,
"version": "0.0.1",
"main": "index.js",
"license": "0BSD",
"scripts": {
"build": "yarn workspace example build"
},
"workspaces": [
"gatsby-theme-minimal",
"example"
]
}
The workspace name that I'd like to change is gatsby-theme-minimal, I'd also like to know how I'd change the other one example when that becomes necessary, so advice on that would also be appreciated. I appreciate that this is probably a simple process but I am as yet unaware of how it is done.
There are two concepts that is used in your question.
The directory name of the workspace. To change it just rename the directory and update workspaces field to refer to the new directory name
The package name of the workspace - it is provided in package.json inside name field for the corresponding workspace. For gatsby-theme-minimal it is provided inside gatsby-theme-minimal/package.json -> name. Just edit package.json and change the name.
After making changes via 1) or 2) or both of them you need to run yarn in order for Yarn to update any installation files that refer to them. If you change workspace package name as per 2) you should also edit and update any code that requires/imports workspace by the old package name.
Related
I need to clone a project of my company on my local machine.
Problem: There is a module required in the main composer.json from our old agency which does not exist anymore, so I don't have the access keys needed to download it, BUT I have the latest code of that module.
The composer.json of that module says its name is "randomagency/import", so I added the code at vendor/randomagency/import. Then I removed the module from the main composer.json.
But I get this error:
Class 'RandomAgency\ProcessPipelines\Helper\Condition\AbstractCondition' not found#0 /var/www/company/src/vendor/composer/ClassLoader.php(444): include()
#1 /var/www/company/src/vendor/composer/ClassLoader.php(322): Composer\Autoload\includeFile()
#2 [internal function]: Composer\Autoload\ClassLoader->loadClass()
#3 [internal function]: spl_autoload_call()
My colleague told me that I need to add the module in the main composer.json under the autoload section, but Im not sure how exactly it works.
The best approach to solve it would be to create a new composer package and replace the agency URL in composer.json with my own, but I need a quick & dirty method for now.
Don't put it into vendor (as it is expected to get removed in time and the name of the vendor-dir is a configuration detail), so technically you have already put it in the wrong location. However, this is easy to recover from, just use a different path within the project root directory, e.g. create a directory where you put packages into (pkg in the following). This works already with autoloader configuration only (if that library requires no other configuration to work):
PSR-4 Autoloader (only) from Project Directory
Then add that path to the projects autoload configuration (see autoload (Composer configuration schema) - Autoload mapping for a PHP autoloader.:
{
"autoload": {
"psr-4": {
"RandomAgency\\Import\\": "pkg/random-agency-import-4.2"
}
}
}
It's good practice you have a single folder for the package - not two as in <vendor>/<package> pattern - and append an identifier of the package version.
Require as Composer Package from Project Directory
Better thought, if that package still contains the composer.json configuration file, add it as a path repository and require it with a version constraint that matches the ./pkg/random-agency-import-4.2/composer.json#/version or * if the "version" member is missing:
{
"require": {
"random-agency/import": "*"
},
"repositories": [
{
"type": "path",
"url": "./pkg/random-agency-import-4.2"
}
]
}
You then don't need to configure the autoloader manually as it is taken from the libraries composer.json configuration. This is equally true for any other configuration part incl. the dependencies of the library.
The great benefit of the path repository is, that is accepts relative paths to your projects configuration file (composer.json).
Compare with your previous understanding:
The best approach to solve it would be to create a new composer package and replace the agency URL in composer.json with my own, but I need a quick & dirty method for now.
You either have solved it by now (the package you require has a composer.json file) or you still need to add the package information, but you don't need to create a new package or exchange URLs.
Package Repository: Inline a Composer Package from Project Directory
That is because you can inline the package as well in Composer with the package repository that now has the path and if you look at /repositories/0/package closely, you can see that this is another composer.json document, just inline at that place (and the /dist member is new):
{
"repositories": [
{
"type": "package",
"package": {
"name": "random-agency/import",
"version": "4.2.0",
"dist": {
"type": "path",
"url": "./pkg/random-agency-import-4.2"
},
"autoload": {
"psr-4": {
"RandomAgency\\Import\\": ""
}
}
}
}
],
"require": {
"random-agency/import": "4.2.0"
}
}
When you do updates etc., Composer then will install the packages files into the vendor folder (where-ever it may be, and regardless how often you remove it).
If - and only if - there is no ./pkg/random-agency-import-4.2/composer.json file, you would need to create a "package", as that is the composer.json in the end.
Alternative: compser.json within the package directory
Similar as you added the autoload part to composer.json and as an alternative to the package repository, you can create the ./pkg/random-agency-import-4.2/composer.json file your own, then the path repository already suffices and it is perhaps easier to configure / maintain as the roots project composer.json file does not expand all the package details.
But that is your preference, just showing that you have a couple of options within the project itself without creating outside / "new" packages.
Figured it out. Had to add it like this:
"autoload": {
"psr-4": {
"RandomAgency\\Import\\": "vendor/random-agency/import"
},
Hi all I am creating this public library
https://github.com/kristijorgji/winstonjs-utils using ts+lerna monorepo
My issue is that although having specified in every package.json
"files": [
"./dist"
],
The file dist/index.d.ts is ignored by the publish command
When I build typescript , the dist folder has two files
But in the published package under dist exists only index.js
I do not have any .npmignore file as you can also see in the public repo I shared.
In all packages packages.json I have specified the typings as well
"main": "dist/index.js",
"types": "dist/index.d.ts",
"files": [
"./dist"
],
Any idea why index.d.ts is excluded from the published packages ? Thanks
I managed to find one solution although might not be the best one.
Nevertheless I am posting in lack of an answer to help everyone facing same issue as me
Solution: I used .npmignore instead of files in package.json
files key seem broken because it ignores index.d.ts files
I used a .npmignore file that excludes unecessary things like
__tests__
coverage
src
tasks
.eslintrc.js
jest.config.js
nodemon.debug.json
nodemon.json
tsconfig.json
then publishing the package worked great with same result as I intended, having only dist folder with index.js index.d.ts inside and package.json and readme.md
I have a project with yarn (v1) workspaces.
project/
packages/
pkgA/
subPkgA1/
pkgB/
package.json has this:
"workspaces": {
"packages": [
"packages/pkgA",
"packages/pkgA/subPkgA1",
"packages/pkgB"]}
note that there's a nested workspace in there.
Top-level has jest#27.4.7 in its package.json.
pkgA has jest#24.9.0 because one of its dependencies requires that version; its package.json has no entry for jest.
pkgA/subPkgA1 has jest#27.4.7 in its package.json, BUT it actually gets 24.9.0 installed in its node_modules/.bin/jest, presumably because its parent workspace has that.
My main question is how to get jest#27.4.7 in the nested package subPkgA1? I tried adding an entry in pkgA's package.json, but that didn't help.
BTW, I know nested workspaces aren't fully supported until Yarn v2, but I can't upgrade right now, and I can't easily move my subpackage out of its parent, so any hacky solution would be better than nothing.
I am using the package teamtnt/laravel-scout-tntsearch-driver and I wish to make a very small change to one of the files within teamtnt/tntsearch which is one of the packages dependencies.
Usually I would:
Create a fork of the package.
Add the repository into my composer.json as follows:
"repositories": [
{"type": "vcs", "url": "https://github.com/user/packagefork"}
],
Require/Upgrade the package to the correct version (usually dev-master) keeping the original name spacing and it all works fine.
However, with a dependency which is not directly included in my composer.json file, this does not seem to work. Do I need to fork both the base package, and the dependency package even though I do not need to change anything within the base?
I am hoping there is a simple way to do this, without having to fork each level.
This was actually quite simple. Not too sure why it did not work originally! Instructions below for anyone wondering:
Fork the package (i.e. GitHub)
Add the repo from your username, to your projects main composer.json as follows:
"repositories": [
{"type": "vcs", "url": "https://github.com/youruser/tntsearch"}
],
Edit the composer.json file within the new fork you created in step 1 (youruser/tntsearch) and create/add to the extras key:
"extra": {
"branch-alias": {
"dev-master": "2.0.x-dev"
}
}
This effectively allows you to install your dev-master version, but allow other packages where this is a dependency to request the 2.0 version (in this case). You do need to be careful in this case that you have forked the correct version and any upgrades are correctly managed later down the line, or things may break!
More info on composer alias here
Require/Upgrade the package using original package namespace, at the dev-master version.
composer require teamtnt/tntsearch:dev-master
The name spacing and package versions will remain the same as before your fork, but the edits from your fork will be pulled into your project instead.
I want to install a package into my local project.For that I'm creating a composer.json file in my project folder is given below, it gives the total vendor folder of that package into my custom folder in my project. Its working fine.....
{
"config": {
"vendor-dir": "/var/www/html/Test2/Testing/Down"
},
}
It gives the package into 'Down' folder.
But, now I want the sub folders or files in that packages to be installed in my custom folders like js/css folders in my project.
For example i want jquery.js file into my local folder path
/var/www/html/Test2/Testing/assests/js
From the package "frameworks/jquery".
For that, what changes are needed in my composer.json file?
Composer is used to bring in packages to support the PHP code of a project, here is how they describe it on the Composer website:
Composer is a tool for dependency management in PHP. It allows you to
declare the libraries your project depends on and it will manage
(install/update) them for you.
In other words, if you need to do logging in your PHP code and decide to use the publicly available monolog package, you use composer to bring that package into your project, then in your PHP code, you can call monolog functions.
Using config to rename the vendor directory is trying to use Composer in a way that doesn't fit the intent of the tool. The vendor directory is used to hold the packages brought in (such as the monolog code). The vendor-dir value is simply renaming that directory.
Since you have GitHub listed as a tag, you could possibly use cloning to get your files to your website directory.
I've modified my composer.json file, it looks like the below:
{
"config": {
"vendor-dir": "/var/www/html/Test2/Testing/Down"
},
"require": {
},
"scripts": {
"post-package-install": [
"php -r \"exec('cp -r /var/www/html/Test2/Testing/Down/frameworks/jquery/* /var/www/html/Test2/Testing/assets/js');\""
]
}
}
It will gives all selected files in a package to my local folder.
Briefly the files in the folder 'frameworks/jquery' are copied into my local 'assets/js' folder.