Document pnpm dlx path

[karlhorky]

I was having trouble finding the location of packages such as create-playwright when running any of these commands (I was trying to edit them to verify that my PR to create-playwright would behave as I wanted):

pnpm dlx create-playwright

pnpx create-playwright

pnpm create playwright

Why

Use cases are developers who:

• use pnpm (maybe using --global, maybe using dlx)
• who want to modify the node_modules files that are currently being run

These developers need to find the files to edit. It's currently not easy or centralized to find the locations of these files.

This PR only deals with the "easy" part by explicitly listing out the resolved paths to these locations.

Alternatives Considered

A single page which ONLY lists out all directory paths that pnpm uses (regardless of whether it's the files or symlinks), so that it's centralized in one place.

It could potentially replace the paths listed on various sections of the npmrc docs page.

Bigger PR though.

cc @KSXGitHub I think this may have been implemented in https://github.com/pnpm/pnpm/pull/7835

[bolt-new-by-stackblitz[bot]]

Run & review this pull request in StackBlitz Codeflow.

[vercel[bot]]

@karlhorky is attempting to deploy a commit to the pnpm Team on Vercel.

A member of the Team first needs to authorize it.

[zkochan]

You should not edit the temporary files created by dlx. I am not against additional docs but I also don't want the users to think it is OK to go there and make changes manually.

That is not a proper way to test your changes locally.

[karlhorky]

I also don't want the users to think it is OK to go there and make changes manually.

Yeah, I understand the sentiment of not wanting to officially recommend something that users could unintentionally misuse and cause confusion. On the other hand, I think there are a lot of things that users could already misuse to cause problems for themselves.

That aside, there is also a benefit to knowing how tools work and where they are saving files. And for power users, it can be a very helpful tool to be able to quickly jump in to the "node_modules location" and modify things for testing purposes. This is a pretty common workflow.

That is not a proper way to test your changes locally.

Hmm... why do you think that? As I mentioned above, I think it's a pretty common workflow for people to edit the node_modules-type location where code from others is running, in order to verify bugfixes in their project without the overhead of cloning + building (+ any other publishing / setup steps) for the package.

[karlhorky]

To be clear though, I don't intend for this PR to add language for an official pnpm recommendation that users edit those files - power users will decide to do this on their own anyway without any recommendation.

[zkochan]

Hmm... why do you think that? As I mentioned above, I think it's a pretty common workflow for people to edit the node_modules-type location where code from others is running, in order to verify bugfixes in their project without the overhead of cloning + building (+ any other publishing / setup steps) for the package.

If you want to do that, then use a temporary project. Create a new directory, run pnpm init, install the package that you want to test and run the package from the temporary project. Don't modify globally installed packages. It is even worse to modify a package in the dlx cache as dlx can remove your changes at any time.

[karlhorky]

If you want to do that, then use a temporary project. Create a new directory, run pnpm init, install the package that you want to test and run the package from the temporary project.

Seems like an ok alternative. But it's extra setup time and friction, and causes the newly-installed package to be run in a different way than the globally installed package. So in a lot of cases, for small fixes or prototyping, I wouldn't use this.

Don't modify globally installed packages. It is even worse to modify a package in the dlx cache as dlx can remove your changes at any time.

Interesting, I didn't know that behavior about dlx. It's something to be extra cautious about.

But about "Don't modify globally installed packages." - any other reason than "dlx can remove your changes at any time"?