Rename jlpm to yarn?

[gnestor]

The jlpm command is a JupyterLab-provided, locked version of the yarn. If you have yarn installed already, you can use the yarn command when developing, and it will use the local version of yarn in jupyterlab/yarn.js when run in the repository or a built application directory.

from https://github.com/jupyterlab/jupyterlab/blob/master/CONTRIBUTING.md#installing-jupyterlab

Given that running yarn in the jupyterlab directory will automatically use the local jlpm binary, why not just rename jlpm to yarn and instruct developers to use yarn install and yarn build?

[blink1073]

We didn't want to impose a version of yarn everywhere for the developer, only when in Jlab directories.

[gnestor]

Right, but what about this line:

If you have yarn installed already, you can use the yarn command when developing, and it will use the local version of yarn in jupyterlab/yarn.js when run in the repository or a built application directory.

It sounds like if the user already has yarn installed globally and they run a yarn command in the lab repo or build directory, it will use the bundled yarn? If that's the case, couldn't we just rename jlpm to yarn and then mention in the docs that it's not a globally-installed yarn to avoid confusion?

[sccolbert]

If that's the case, couldn't we just rename jlpm to yarn and then mention in the docs that it's not a globally-installed yarn to avoid confusion?

That sounds to me like it would generate a lot of confusion. We'd in essence be install a system command on the user's machine called yarn which is not actually yarn.

Also, the result of which yarn would be odd.

[gnestor]

We'd in essence be install a system command on the user's machine called yarn which is not actually yarn.

But it sounds like that's what we're already doing when yarn is run from the lab repo or build directory, right? We're using jlpm vs. the globally-installed yarn. So why not just instruct users to use yarn install and yarn build vs. jlpm install and jlpm build? It seems like introducing a new jlpm command that behaves just like npm/yarn might be more confusing?

[sccolbert]

But it sounds like that's what we're already doing when yarn is run from the lab repo or build directory, right?

That's how yarn works. What's happening is the global yarn command is seeing that there's a locally installed yarn, and is delegating to that instead of the global yarn. This is a common pattern for node utilities. It's not something we're doing explicitly.

If we didnt provide the jlpm command, we either force the user to have yarn installed globally (so that they could actually type yarn and have it work), or we would have to have some form of npm run yarn command.

[jasongrout]

For reference, here is where the redirection is specified:

jupyterlab/.yarnrc

Line 1 in 891875a

yarn-path "./jupyterlab/yarn.js"

(see https://yarnpkg.com/lang/en/docs/yarnrc/#toc-yarn-path).