Is there a "correct" way to have globally available scripts w/ yarn workspaces?
Let's take typescript as an example. If I install it at the root level using yarn add -W typescript it's not available in any of my workspaces:
child-workspace$ yarn tsc
yarn run v1.22.10
error Command "tsc" not found.
Now I can install tsc into every workspace, along with babel, jest, etc etc etc, but that's awfully redundant. I'm looking for a way to have tools at the global level that are used by each of the workspaces.
Even better, if possible, would be if there were a way to have a "build" workspace and have all the scripts from that globally available so they can be cleanly separated from the workspace root.
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.
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 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.
I am newbie in Node.js.
Whenever I want to install a package, I do it like
"npm install -g package-name"
What I have seen inside my node applications there is a dir "node_modules" been created and all the installed modules are there.
Then I want to use "grunt" for automating my tests for frontend javascirpt unit tests.
And I ran the command for installing "npm install -g grunt" but when I go inside my test directory and run grunt I get "Fatal error: Unable to find local grunt." But if I install it inside the "test" directory it works fine.
My project structure like below:
-backend
-tests
-model
-node_modules
-package.json
-others
-frontend
-tests
-js
-package.json
-node_modules
-others
How I can manage node packages from a single pacakge.json and run the tests separately in frontend and backend? What are the optimized way of doing this stuff?
Thanks in advance.
The -g flag in npm will install the module globally -- this is how things like grunt work as a CLI tool, but for your dependencies, you probably just want them to be installed in your node_modules folder, defined in your package.json.
Are you browserifying your front-end modules? You most likely do not want both your front and back end to have the same set of dependencies, best to keep them separate package.json manifests. Are your frontend modules just grunt tasks? Running grunt in either frontend or backend directories will call the gruntfile only there.
Keep these two directories separate -- will save a lot of headache in the future.