Do you want to request a feature or report a bug?
feature request

What is the current behavior?
Currently yarn why won't indicate any package info in the resolutions field

If the current behavior is a bug, please provide the steps to reproduce.

1. install a package with any version, e.g "pkg": "^1.0.0"
2. add resolutions field in package.json, pkg: "1.0.0"
3. upd

So if you happen to insert invalid version string when requiring package, it will still write it into composer.json and nothing works after that. So for example; composer require phpunit/phpunit:"8.3.3 as ^8.3"

My composer.json:

{
    "require": {
        "phpunit/phpunit": "8.3.3 as ^8.3"
    }
}

Output of composer diagnose:

$ composer diagnose
        

Homebrew/livecheck provides various automated ways of detecting formulae updates.

Repology provides an API that provides details on whether a Homebrew package is outdated e.g. https://repology.org/metapackage/boost/versions

A separate Ruby application that can be trivially deployed on e

I often forget the exact syntax and semantics of the version constraints.
It would be great to have that readily accessible from the command line
with (for example) dep help constraints.

The self.options object inside a main recipe has .get_safe attribute to get the value of a option or a default value if it does not exist.
But in a test package conanfile.py, this does not exist.

I believe options object in the main and test recipe should have the same options.

Environment Details (include every applicable attribute)

• Operating System+version: Linux+Windows

Is your feature request related to a problem? Please describe.

Not related to a problem

Describe the solution you'd like

We opened #808 to discuss how we might use GitHub actions. At the time, this repo didn't have actions enabled. Now that it does, we should try them out for some of the things in that thread.

_Edit from @arschles - we have focused this issue to just the twitte

Hi everyone 👋 , thank you very much for the work on Rubygems/Bundler.

I found out an issue related to bundle exec which set the RUBYOPT env variables to something like: -r/opt/rubies/2.7.1/lib/ruby/2.7.0/bundler/setup

When using Bundler.with_unbundled_env, bundler is supposed is to strip out the -r bundler/setup part but the regex is incorrect and assume the path is relative wherea

Describe the user story

Currently when running yarn upgrade-interactive it lists all installed packages and lazily displays new packages. When working on a project that has many dependencies (>20) this can get out of hand easily where you're scrolling for a while until you've "found" the first package with a new available version.

Describe the solution you'd like

I suggest