Maël Nison
Maël Nison
> How can I opt out this behavior? Directly call the shell you want to use: ```json { "foo": "bash -c 'ls *'" } ```
> `resolutions` field in `package.json` doesn't update `yarn.lock`? This is expected - the `resolutions` field only has effect while it's there. It's important, otherwise your ranges would be "eternally" locked...
> Theoretically, could `yarn set resolution` update only the `package.json` manifest instead of writing to `yarn.lock`? That way, both ways would be equivalent. No; the `resolutions` field and `yarn set...
Reopening for `--save`
Sure! I think just blocking `yarn set version` in the home directory would be reasonable (and perhaps add a `--skip-home-check` in case someone really needs it?)
That would be a wontfix as third-party binaries aren't portable and cannot be run from zip archives. At worst, you can make a JS script that uses `execFileSync`.
> Side-question: Is cross-platform portability a goal of berry or is it more the implementation detail of not being able to run them from zip archives? A bit of both...
Try replacing `~` by `$HOME`?
For the syntax, but I'm don't think `$HOME` is exposed on Windows, as we don't normalize the environment yet (would be easy to fix, though) 🤔
I think it'd be ok to implement more Yarn-specific behaviors into ZipFS - I think @paul-soporan had some ideas about that.