Support yarn workspaces

[kachkaev]

Yarn has workspaces feature, which is commonly used to manage monorepos. It lets developers keep multiple npm packages in a single repository and manipulate them from the root folder.

A typical project setup may look like this:

/
  packages/
    package-one/
      package.json
    package-two/
      package.json
package.json

In root package.json:

{
  "private": true,
  "workspaces": ["packages/*"]
}

packages/*/package.json files look like the normal ones, i.e. with their own scripts and dependencies.

Things you can do as a developer:

## install all deps everywhere and link `package-one` with `package-two` if needed
yarn

## add lodash package as a dependency to package-one
yarn workspace package-one add lodash

## remove lodash from package-one
yarn workspace package-one remove lodash

## same as to run "yarn do-something" inside packages/package-two
yarn workspace package-two do-something

## list locations of package-one and package-two as json
yarn workspaces info

It'd be awesome if yarn-completion helped in these cases:

yarn workspace package-o
yarn workspace package-one

yarn workspace package-one ad
yarn workspace package-one add

yarn workspace package-one remove lo
yarn workspace package-one remove lodash

yarn workspace package-two do-s
yarn workspace package-two do-something

yarn workspaces i
yarn workspaces info

[dsifford]

Thanks for the feedback @kachkaev

I tried giving this a go when adding in the initial support for workspaces, but it ended up being too difficult to do without introducing another dependency for JSON parsing (jq, for example).

If you have any ideas on how to go about this, but without using an external dependency or a non-posix command, I'm all for it.

[dsifford]

That said, I don't recall specifically what what so difficult.

It may have been the globbing. Node globbing works differently than bash globbing.

[kachkaev]

Unfortunately I'm not very strong in bash scripts, so am not sure I'll be able to help here. But I guess that having this issue existing and open may increase a chance that someone gives it a go 🙂

BTW what do you need to run glob? IMO calling yarn workspaces info and parsing JSON is the only right way to go to ensure a 100% correctness – I would not try to search for workarounds. The packages may be located not just in packages/* and it's hard to guess what alternative syntaxes future versions of yarn may support. There are two notations already and I'm using both in my package.json files:

  "workspaces": ["packages/*"]

  "workspaces": {
    "packages": ["packages/*"],
    "nohoist": ["**/@types/**"]
  },

Also curious what you think of making yarn-completion a node module, i.e. something written in JavaScript or TypeScript. Coding should become easier than with bash, which may attract more contributors. Testing of features will be easier too (e.g. with jest) and there'll be less dependencies on how system libs like sed work (remember https://github.com/dsifford/yarn-completion/issues/10). Aren't node cli apps fast enough to work as autocompletion tools?

[dsifford]

Never tried yarn workspaces info -- that helps a lot actually. When I wrote the completions for workspaces initially, the commands weren't actually active yet so I wasn't sure what that command would even do. Good stuff.

Also curious what you think of making yarn-completion a node module, i.e. something written in JavaScript or TypeScript

That sounds good in theory, but in order for bash to parse a completion, it must be written in bash.

Similar completion logic might be written in javascript (e.g. npm's completions), but the output that is passed to bash-completion must be a bash file. That's why in order to use npm completions, you need to do..

source <(npm completion)

this turns the output of npm completion into a file input redirect and allows bash to source it.

The problem with doing it the way npm does it is that it creates a noticable amount of lag time, which I find mildly infuriating.

Aren't node cli apps fast enough to work as autocompletion tools?

Sure. But again, it's not about speed, it's about the requirements of bash completion in general.