I am trying to test a cli (feathers-cli) that I am working on. I have cloned it's primary dependancy (feathers-generator) and made my modifications, this is what I have done.
Gone into feathers-generator (master branch) and run yarn link
Gone into feathers-cli (3.0 branch) and run yarn link "feathers-generator"
Run yarn link
created a new directory, removed my existing version of feathers-cli
Run yarn link "feathers-cli" then run yarn global add "feathers-cli"
feathers however, at this point it is using the regular version it has pulled from npm. I have looked through the yarn docs and can't seem to find anything about globally linking packages. How do I approach this?
With yarn v1.19 you can do:
yarn global add file:/fullpath/to/myproject
Yarn, unfortunately, does not seem to support this directly in any way. The best thing I've found is to symbolically link the file to the user's yarn bin folder.
On Windows: %LOCALAPPDATA%/Yarn/bin
On Linux: ~/.yarn/bin/
Easiest way is to test within a node project, even if it's a global cli tool.
Example
Say I want to test a global tool my-yarn-cli, which has a few commands new, --help, --version, etc...
In the cli tool directory, yarn link this makes the local version of my-yarn-cli available to yarn.
In an empty project use yarn link my-yarn-cli, this adds a reference to the local version of my-yarn-cli
Test out commands using yarn as a proxy, for example:
yarn my-yarn-cli --help
yarn my-yarn-cli --version
yarn my-yarn-cli new TEST_ARGUMENT
This has been a useful workflow for me, and is much better than messing with symlinks or copying directories.
Related
I'm trying to build a Docker image for a service built using yarn workspaces inside a monorepo and I can't figure out how to get an appropriate node_modules inside of it. Is there any way to run yarn install that will create a full blown file tree structure for node_modules? As far as I can tell, there are two issues:
Hoisting of common dependencies up into node_modules in the project root
Symlinking of local modules in node_modules to their respective directories.
Is there any way to get around this?
(yarn version: 1.22.10)
Well, it turns out that the (pretty obvious) answer is to run yarn install inside the docker container when it is being built. That way the service is no longer seen as being a workspace.
As a team practice, I would like to force my teammate to use yarn install/ run but not npm install/ run.
Is it possible to force a package.json 's dependency be installed only via yarn install or package.json's script be run only via yarn run?
If it cannot be done, can I at least get a warning when using npm install?
Again, this is only to align the team practice, so that reduces the possibility of error/ problem produced during dev/ops. Thanks
One of the way I can think of is CI can set a rules to detect if there is new file package-lock.json file being created, make the build fail. The developer will then realized he made a mistake since his build failed.
Alternatively you can also rely on husky pre-commit hook, which essentially runs a command to check if package-lock.json existed everytime developer trying to run git commit.
Me and a coworker are working on the deploy of some APIs that have some sharedlibs in common.
The thing is, he said that workspaces shouldn't be used in production, but no reason was presented to defend that. I came with the following setup:
Set SSH Keys from the remote for pull the repository
Run yarn workspace <api-name> install for a single API
Run yarn build for ES6/Babel
Run API from dist folder. And we're done. No need for bash scripts or NPM private packages.
I see nothing wrong with your setup. Yarn Workspaces is used to simplify management tasks on your code tree (and I see install script as code). It does not really matters whether you run yarn workspace <api-name> install or cd <api-name>; ./install.sh - but the former is less error-prone.
Yarn 2.0 is bringing PnP to the table, but I don't really understand how I can run javascript with the simple node command anymore if the file has dependencies in the npm registry. node looks for node_modules folders to find dependencies, but since PnP removes the node_modules folder entirely, do I need to use a command other than node now? Or will node introduce some new flag to read the .pnp.js file instad of recursively looking upwards for the nearest node_modules?
Answer from Yarn 2 PnP docs:
Because Node had no concept of packages, it also didn't know whether a file was meant to be accessed (versus being available by the sheer virtue of hoisting). It was entirely possible that the code you wrote worked one day in development but broke later in production because you forgot to list one of your dependencies in your package.json.
For your answer that can you can you run using command node index.js.
You need to add a script in your package.json scripts section like "start": "node index.js" and then run yarn run start
yarn node index.js. See the yarn 2 (berry) docs. https://yarnpkg.com/cli/node
I cannot make yarn workspaces work on Azure Web Service and I cannot upgrade yarn.
I have an application deployed as Azure Web Service. It uses yarn workspaces. Unfortunately during yarn install the error occurs
[3/4] Linking dependencies...
error An unexpected error occurred: "ENOENT: no such file or directory, lstat '/home/site/wwwroot/node_modules/#gsx/common'".
info If you think this is a bug, please open a bug report with the information provided in "/home/site/wwwroot/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
I read that upgrading the yarn can solve the problem. Azure by default comes with yarn 1.6.0.
I have deploy.sh file in my repository, so I can customize the deployment process. I would like to add command to upgrade yarn.
I tried to achieve it in two ways:
npm install -g yarn
and
sudo npm install -g yarn
Both of them fails. In the first situation I get a message that I do not have enough permissions. In the second one the logs say that there is no command sudo.
Do you have an idea, how can I upgrade yarn?
Please take a look at this repo and give it a try. All you'd have to do is copy the deploy.cmd and .deployment files from the above repo to yours, which would make Kudu use this script instead of the default one. Hope this helps.