[Bug] yarn up does not properly update non-npm dependencies

[andreialecu]

• I'd be willing to implement a fix

Describe the bug

Running yarn up pkg where pkg is a git dependency removes the git dependency and replaces it with a npm dependency.

To Reproduce

Reproduction

await yarn('init', '-y');
await yarn('add', 'left-pad@left-pad/left-pad');
await yarn('up', 'left-pad')

expect(require("./package.json").dependencies["left-pad"]).toEqual("left-pad/left-pad")

[andreialecu]

This is particularly dangerous if a dependency's name is something common (eg. utils) and unrelated to the utils on npm .

I think the expected behavior or yarn up pkg would be to refresh pkg to the latest commit available without changing its resolution.

Low risk, but in theory, a malicious package could be created on npm to target some internal package used at some company, and run some install script once someone runs yarn up project1-utils. (think previous employee with knowledge of internal package names, etc)

[yarnbot]

This issue reproduces on master:

Error: expect(received).toEqual(expected) // deep equality

Expected: "left-pad/left-pad"
Received: "^1.3.0"
    at module.exports (evalmachine.<anonymous>:6:60)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async /github/workspace/.yarn/cache/@arcanis-sherlock-npm-1.0.38-d4f5e2dbf3-63f998598d.zip/node_modules/@arcanis/sherlock/lib/executeRepro.js:56:13
    at async executeInTempDirectory (/github/workspace/.yarn/cache/@arcanis-sherlock-npm-1.0.38-d4f5e2dbf3-63f998598d.zip/node_modules/@arcanis/sherlock/lib/executeRepro.js:17:16)
    at async Object.executeRepro (/github/workspace/.yarn/cache/@arcanis-sherlock-npm-1.0.38-d4f5e2dbf3-63f998598d.zip/node_modules/@arcanis/sherlock/lib/executeRepro.js:24:12)
    at async ExecCommand.execute (/github/workspace/.yarn/cache/@arcanis-sherlock-npm-1.0.38-d4f5e2dbf3-63f998598d.zip/node_modules/@arcanis/sherlock/lib/commands/exec.js:25:38)
    at async ExecCommand.validateAndExecute (/github/workspace/.yarn/cache/clipanion-npm-2.0.0-rc.16-b9444aaf89-a57989414f.zip/node_modules/clipanion/lib/advanced/Command.js:161:26)
    at async Cli.run (/github/workspace/.yarn/cache/clipanion-npm-2.0.0-rc.16-b9444aaf89-a57989414f.zip/node_modules/clipanion/lib/advanced/Cli.js:74:24)
    at async Cli.runExit (/github/workspace/.yarn/cache/clipanion-npm-2.0.0-rc.16-b9444aaf89-a57989414f.zip/node_modules/clipanion/lib/advanced/Cli.js:83:28)

[brunoclima]

I'm also getting an error [YN0027] when trying to update a private package using a git+ssh url. But when I put the entire package-name@remote-url like I did in yarn add, it updates just fine. I tought he used the same package name to resolve the url in my package.json. Am I missing something?

[Nantris]

This and other handling of non-npm packages is, frankly, insane. I find it hard to view any of this as an upgrade when previously supported features are non-functional half a decade after release - and in other threads are even referred to as "feature requests"...

[torce]

Today I had an internal git npm package replaced with some random package from npm after doing an upgrade.
This was working with yarn 1 and this behavior is very surprising.
This feature may be a bit niche, but the security implications are very serious.

[Nantris]

I'd really like to see a reply from the maintainers here. This can indeed present serious problems.