g-plane/zsh-yarn-autocompletions

Suggestions do not handle scripts containing `:` in other workspaces

adrienharnay opened this issue · 6 comments

Hello,

Per the docs: https://yarnpkg.com/getting-started/qa#how-to-share-scripts-between-workspaces, a script containing : is available from other workspaces (but only if is is defined only once, else yarn doesn't know which one to resolve).

Do you think the plugin could also:

  • list scripts with : in their name
  • only if they are defined once in all workspaces
    ?

Thanks in advance and have a nice day

This plugin can already list scripts that contains : as the picture in readme shows. Or, is the feature you mentioned different?

Hi, sorry if the description was not clear. I understand the plugin can already list scripts with : in their names, but per the docs it should also list scripts from other workspaces if they have : in their name.

Example:

root (scripts: lint, lint:all)
|____ package1 (scripts: test:local, test:package1)
|____ package2 (scripts: test:local, test:package2)
  1. If you try to run yarn lint:
    a. at the root, it works (the workspace defined it)
    b. in package1 and package2, it doesn't work (the script if not accessible from everywhere because it doesn't have : in its name

  2. If you try to run yarn lint:all
    a. at the root, it works (the workspace defined it)
    b. in package1 and package2, it works as well (the script is available from everywhere because it contains :)

  3. If you try to run yarn test:local
    a. at the root, it doesn't work (the script contains :, but it is defined in multiple workspaces and therefore can only be called from a workspace that defined it)
    b. in package1 and package2, it works (the workspaces defined it)

  4. If you try to run yarn test:package1
    a. at the root and in package2, it works (the script contains :, and is only defined by one workspace, so available everywhere)
    b. in package1, it works (the workspace defined it)

Currently, the plugin accounts for 1.a., 2.a., 3.b., 4.b.

I think it would need to also account for 2.b. and 4.a., while watching for 1.b. and 3.a.

Please let me know if this is clearer, and have a nice week-end!

This looks that it will increase the complexity, because this plugin should simulate as Yarn and do workspace resolution to read all packages in a workspace.

I think we can get the list of workspaces by reading the workspaces key in the root package.json, what do you think?

Actually, it allows globs. If we support globs, there will be two disadvantages:

  1. Logic will become complex for this plugin.
  2. Expanding globs will increase plugin startup time.

Alright, thanks anyway!