Skip to content

Implements transparent commands - #19

Merged
arcanis merged 4 commits into
mainfrom
mael/init-exec
Sep 30, 2020
Merged

arcanis merged 4 commits into
mainfrom
mael/init-exec

Conversation

@arcanis

@arcanis arcanis commented Sep 30, 2020 •

Copy link
Copy Markdown
Contributor

It's currently fairly annoying to run the init commands, because they go through the jumper, which detects that there is no local project, asks if it should create one, spawns the init command, and fails because there's already a package.json. Additionally, running yarn dlx or pnpx isn't possible at the moment from (respectively) non-Yarn or non-pnpm projects.

This diff fixes that by defining a set of "transparent commands". The jumpers will allow those commands to be used regardless of the general environment - making it possible to run pnpx within Yarn projects, and running yarn init without prompts.

Fixes #1, fixes #2

@arcanis

arcanis commented Sep 30, 2020

Copy link
Copy Markdown
Contributor Author

I've also removed Enquirer. While it's a good idea in theory, it's very impractical as it:

  • causes spurious prompts to appear when running in the wrong directories
  • causes package.json to appear on the filesystem - problematic if you're for example in the home folder

Instead, Corepack will silently accept any package manager and use their LKG releases (similar to what already happens when you're inside a non-configured project). It doesn't change much, the only downside being that the packageManager field adoption will be lower, but it's worth it if it means less disruption for the users. Additionally, the init commands (such as yarn init) still have the ability to set the packageManager field themselves if they wish to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Init workflow Global packages

1 participant