Do you want to request a feature or report a bug?
feature
What is the current behavior?
yarn run <script>
only works if run in the project's root directory. If run in a subdirectory of the project, it reports
error Couldn't find a package.json file in ".../project/subdirectory"
If the current behavior is a bug, please provide the steps to reproduce.
Try running an npm script in a subdirectory of a project with a package.json in its root directory.
What is the expected behavior?
npm run <script>
works both in the project's root directory and in subdirectories of the project. It executes the script with the current directory set to the directory which contains the package.json
(most usually the project's root directory).
The benefits of this feature are clear, match npm behavior, and should be straightforward to implement. I would be happy to contribute this feature given a green light from the maintainers and some guidance.
Please mention your node.js, yarn and operating system version.
| | |
| --- | --- |
| Node.js | 7.4.0 |
| yarn | 0.18.1 |
| OS | macOS Sierra v10.12.2 |
On the flip side, when I run yarn add <package>
in a subdirectory, it creates a new node_modules
, package.json
and yarn.lock
in the subdirectory, instead of matching npm install --save
's behavior and installing in the root.
If this is the intended behavior, I think yarn's documentation could use some improvement and be more explicit about yarn add
's behavior in project subdirectories.
First time using yarn, just ran into this as an issue at T + 10 minutes. =D
Love to see some comments on this topic. Is this something yarn is not planning on supporting at all?
I am facing the same issue.
scripts: {
"dev": "node someDir/someFile.js"
}
yarn run dev
shows: error Couldn't find a package.json file in ".../someDir/" while npm run dev
works as expected. I guess this is something many people would like to have.
same issue here. NPM works fine when run in a subdirectory, and adds a dependency to the parent package.json rather than creating a new one which seems like the correct behavior. Is there some way around YARN doing this? A parameter a ...?
In the interim, I've created this wrapper script:
#!/usr/bin/env node
/* eslint-env node */
const yarnbin = '/usr/local/bin/yarn',
fs = require('fs'),
path = require('path'),
spawn = require('child_process').spawn,
validatePackageDirectory = (dir) => -1 !== fs.readdirSync(dir).indexOf('package.json'),
pDir = (()=>{
let pathCheck=process.cwd();
while(pathCheck.length>4) {
if(validatePackageDirectory(pathCheck)){
return pathCheck;
}
pathCheck=path.normalize(path.join(pathCheck,'..'));
}
return;
})();
if(pDir){
try {
spawn(yarnbin,process.argv.slice(2),{
cwd: pDir,
stdio: 'inherit'
}).on('close',(code)=>{
process.exit(code);
});
} catch (e) {
process.exit(1002);
}
} else {
/* eslint-disable no-console */
console.log(`Couldn't locate package.json`);
process.exit(1001);
/* eslint-enable no-console */
}
It will execute yarn
in the first directory upwards that contains a package.json
(edit yarnbin
to point to where you have yarn
installed). I put this in my home dir in a directory higher in the path search order and named it yarn
as a drop in replacement. If starting a new repo, you can either explicitly run the real yarn
, or touch package.json
first.
Edit: fixed for correctly returning the return code of the real yarn.
I would also love to see an option to define yarn IN a subdirectory, so we could run yarn ...
from a parent directory.
I have a project with both server and client folders, and I'd love to NOT have to cd client
before running a yarn command.
A simple solution would be to add --cwd
option to .yarnrc
@goldylucks You should look at Yarn Workspaces and Lerna.
thanks @shdwjk , it doens't seem to support the specific behavior I'm after
Look at https://yarnpkg.com/en/docs/cli/workspace
yarn workspace client ...
I appreciate the link, and it doesn't fit my use case. I want to do yarn
add some-package
on root folder and have it automatically add that package
to client/node_modules and also modify client/yarn.lock instead of current
directoty's yarn.lock.
I don't see a why in workspaces to achieve that. Am I missing something?
On Sat, Jul 27, 2019 at 4:54 PM Aaron C. Meadows notifications@github.com
wrote:
Look at https://yarnpkg.com/en/docs/cli/workspace
yarn workspace client ...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yarnpkg/yarn/issues/2459?email_source=notifications&email_token=ABVEADG3ZM2HGGTQAI5SG5DQBRHRDA5CNFSM4C4ROUX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD26L4FA#issuecomment-515685908,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABVEADAR3NYARA6MFTEXPDLQBRHRDANCNFSM4C4ROUXQ
.
For anyone trying to achieve the same behavior in 2020, there's now an option --cwd
yarn --cwd <path-to-the-desired-directory> run <script>
Most helpful comment
For anyone trying to achieve the same behavior in 2020, there's now an option
--cwd
yarn --cwd <path-to-the-desired-directory> run <script>