sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: Allow "Ctrl+Win+Alt + Arrow" shortcut to expand a window also when "move windows based on their position" is disabled
Labels: Idea-Enhancement,Product-FancyZones

## 📝 Provide a description of the new feature

Pull request #6446 added a nice shortcut `Ctrl+Win+Alt + Arrow key` to expand/shrink a window across multiple zones, but it only works when the option "*Move windows based on their position*" is enabled.

This feature seems somewhat unrelated to this setting and it would be awesome **if it also worked while the setting is off**. The setting overrides native Windows functionality around `Win + Up/Down`, while the `Ctrl+Win+Alt` shortcut is otherwise unused.

The reason why I want to keep the setting off is that it prevents the shortcut `Win + Up` from maximizing a window -- and there does not seem to exist any other keyboard-only way for maximization otherwise. But I would still like to expand windows to multiple zones with the keyboard.

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: create-react-app
Issue: CSS import from sibling package inside monorepo fails
Labels: needs triage,issue: bug report

### Describe the bug

CSS imports like

```css
@import '~@my-company/package1/index.css';
```

break the build when `@my-company/package1` is a sibling monorepo package, where monorepo is controlled by [yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/).

It's a regression / change in behavior comparing to `react-scripts@3`.

### Environment

```
  System:
    OS: macOS 10.15.7
    CPU: (8) x64 Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz
  Binaries:
    Node: 12.18.3 - ~/.nvm/versions/node/v12.18.3/bin/node
    Yarn: 1.22.5 - /usr/local/bin/yarn
    npm: 6.14.6 - ~/.nvm/versions/node/v12.18.3/bin/npm
  Browsers:
    Chrome: 80.0.3987.149
    Safari: 13.1.3
  npmPackages:
    react:  17.0.1 
    react-dom:  17.0.1 
    react-scripts:  4.0.1 
```

### Steps to reproduce

1. Create new `yarn workspaces` monorepo
2. Create monorepo package containing valid CSS file
3. Initialize another monorepo package with `yarn create react-app`
4. From the CRA app package's `index.css` import CSS from a sibling package using syntax `@import '~scope/sibling-package/file.css';`

See [react-scripts-4-import-monorepo-package-css-issue](https://github.com/ikornienko/react-scripts-4-import-monorepo-package-css-issue) for a reproducible demo.

### Expected behavior

Build works fine and `react-scripts@4` is able to build the application same as `react-scripts@3` does it.

### Actual behavior

Build error:

```
ModuleNotFoundError: Module not found: Error: You attempted to import ../../package1/index.css which falls outside of the project src/ directory. Relative imports outside of src/ are not supported.
You can either move it inside src/, or add a symlink to it from project's node_modules/.
```

### Reproducible demo

Please find it in [react-scripts-4-import-monorepo-package-css-issue](https://github.com/ikornienko/react-scripts-4-import-monorepo-package-css-issue), the README there explains the demo in details.
Repository: godot
Issue: Shadow overlap sprite with shaded and billboard flags enabled
Labels: bug,topic:rendering,topic:3d

**Godot v3.2.3:**


**OS/device including version:**
Linux 5.9.16-1-MANJARO 
Tested with GLES2 and 3, same problem. 

**Issue description:**
I want a sprites in billboard mode to cast shadows in a 3D environment. I've enabled billboard mode, check "Transparent", "Shaded" and "Double sided" flags and set "Alpha Cut" to "Opaque Pre-Pass". It casts shadows as expected, but there is some ugly shadow artifacts in front of my sprite, like this : 

![Capture1](https://user-images.githubusercontent.com/59919226/104387551-ab463780-5537-11eb-89f3-048e495eba2f.png)

This problem only occurs when I enable the "Shaded" flag. It work just fine when I disable it, like this : 

![Capture2](https://user-images.githubusercontent.com/59919226/104387792-27d91600-5538-11eb-8dd1-174e17222d8e.png)

**Steps to reproduce:**
I tried on different computers, with both Linux and Windows, I ran it with GLES 2 & 3, I tried with the Sprite node and the MeshInstance one, with Spot, Directional Omni Lights,  still the same... It really seems to be the Shaded flag fault.

To reproduce you just have to instantiate a Ground, a Sprite, and a OmniLight with Shadow enabled, set options described above on the sprite and watch.

**Minimal reproduction project:**
[BugReport.zip](https://github.com/godotengine/godot/files/5805491/BugReport.zip)
Repository: rust
Issue: Additional bounds are required for const generics using associated constants
Labels: A-diagnostics,T-compiler,A-const-generics,requires-nightly,F-generic_const_exprs

Example below. Based on the description in #76560, I'd expect to not be required to add `[(); From::DIM]:` and `[(); To::DIM]` bounds to `Transform` because the associated consts are inherent to the trait's definition and thus are public APIs.

```rust
#![feature(generic_const_exprs)]

trait Vector {
    type Scalar;
    const DIM: usize;
}

struct Transform<From, To>
where
    From: Vector,
    To: Vector<Scalar = From::Scalar>,
{
    columns: [[From::Scalar; From::DIM]; To::DIM],
}
```

([Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=e5e1a91564d918736426fb31777e9a0a))
Repository: pytorch
Issue: Standalone OSS RPC benchmark
Labels: oncall: distributed,triaged,better-engineering,module: rpc

## 🚀 Feature
A few unittests in the RPC framework can currently proxy as a rough benchmark for RPC call overhead, see for example https://github.com/pytorch/pytorch/blob/master/torch/testing/_internal/distributed/rpc/rpc_test.py#L2027. We also have a few different benchmarks for internal-specific workloads, but no OSS benchmark that can quickly and reliably be used to benchmark one-off changes to the framework that may impact performance (positively or negatively).

## Motivation

Ensure PRs do not regress performance of the RPC framework and ensure that changes such as https://github.com/pytorch/pytorch/pull/49910 have the desired result in terms of enhanced performance. 

## Pitch

Identify the most common production workloads (PS architecture, RL workloads, etc) and integrate them into a single standalone benchmark. This benchmark should aim to simulate real-world production workloads as closely as possible, but does not need to train the model to convergence.

## Additional context

@osandoval-fb has kicked off work along this line, adding an RPC benchmark for RL workloads. That work can be extended to support the use cases described above. 


cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @jjlilley @osalpekar @jiayisuse @agolynski @SciPioneer @H-Huang @mrzzd
Repository: go
Issue: encoding/json: clarify what happens when multiple items match the same field
Labels: NeedsInvestigation

This test I added to encoding/json

```
func TestUnmarshalCase(t *testing.T) {
	var v struct {
		Dist string `json:"dist"`
	}

	Unmarshal([]byte(`{"dist": "ok", "Dist": "KO"}`), &v)
	t.Logf("%+v", v)

	Unmarshal([]byte(`{"Dist": "ok", "dist": "KO"}`), &v)
	t.Logf("%+v", v)
}
```

prints

```
    x_test.go:13: {Dist:KO}
    x_test.go:16: {Dist:KO}
```

The comment says Unmarshal "prefers" exact matches, but if there are no words about what happens if multiple fields match.

It's clearly an odd case, but clarity would be nice. I expected the exact match to win always.
Repository: TypeScript
Issue: Include re-exports of symbols when suggestion auto-import targets
Labels: Suggestion,Awaiting More Feedback

*TS Template added by @mjbvz*

**TypeScript Version**: 4.2.0-dev.20210112

**Search Terms**
- auto import
- export

---


<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->
- VSCode Version:
- OS Version:

Steps to Reproduce:

a.js
```js
export function test() {}
```

b.js
```js
export { test } from './a';
```

when i type `test`, only `a.js` in the suggstion list, `b.js` not.

but i want import `test` from 'b.js';

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes
Repository: ant-design
Issue: Modal 下 destroyOnClose 属性 失效
Labels: 🐛 Bug,help wanted,Inactive

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[https://fvrw0.csb.app/](https://fvrw0.csb.app/)

### Steps to reproduce
modal下使用video标签，播放后，关闭modal video or audio标签依然播放， 且重新打开modal 依然存在

### What is expected?
modal关闭后销毁媒体标签

### What is actually happening?
modal关闭后未销毁标签

| Environment | Info |
|---|---|
| antd | 4.10.2 |
| React | 16.12.0 |
| System | win10 |
| Browser | firefox |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: [RFC] Make RRef proxy APIs non-blocking
Labels: triaged,module: rpc

## 🚀 Feature

Currently, RRef proxy APIs first call into `rref._get_type()` which issues a blocking rpc_sync call, see callsite: https://github.com/pytorch/pytorch/blob/master/torch/distributed/rpc/rref_proxy.py#L15. This currently means that all initial calls to rref._get_type will block on successful creation of rpc.remote() and can hang/fail if rpc.remote hangs/fails. 

It might be better to add an option for `rref._get_type()` to return a future (it can just be a completed future in the case we are already on owner or returning cached result). Then, we can use this option in rref proxy logic and add most of the rref proxy logic as a callback to `rref._get_type()`. This will make  `rref.rpc_async()` non-blocking and immediately return a future. 

## Motivation
The main motivation is performance to avoid the blocking behavior, and consistency with existing RPC APIs that immediately return a future without blocking on network. 

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @rohan-varma @jjlilley @osalpekar @jiayisuse
Repository: TypeScript
Issue: [Regression 3.9 -> 4.X] Variadic tuple type is not correctly inferred
Labels: Needs Investigation

# Bug Report

### 🔎 Search Terms

variadic tuple, regression, inference

### 🕗 Version & Regression Information

- This changed between versions 3.9.X and 4.X.X

### ⏯ Playground Link

[Typescript 3.9 (works as expected)](https://www.typescriptlang.org/play?ts=3.9.7#code/C4TwDgpgBAyglgOwNYB4AqA+KBeKAKYALigQFcBbAIwgCcAaKMAQxABsB7JgE2LQEocWAG7s4XANwAoSaEhQACjXZdSAY1rosuAsTJVaDAM6IkxeMk0Dsw0ROmzoAUQAewGk1XAAwuwTAIfuhQEK4BXIZQANqKymoapMgI7ADuCBgMAHRZMSrqNCgJSEmpGJEAumVaUADeklD1UUhQiFBIECDsAGZQaGW8kUhlwaEI4QpKuRqInbRQAKpYAPzzULoQQrRSAL7SnQmecL5QquxUiBAA6nDAABZBIf6jEdETcfmFxWmZ2a95BYkpNLlMoMBZ4OoNToIYh4LIZJg0ADmhmILjcHm8vkewEsgnmdAh9ThhnYpBo6hRPUkfGIOTeKAWNUJUBoEGAZIQUASXAgnXOXCgTAiTAQIG2u32wEOnK6mjw0J6NPGsT+mCZDRZbI5XNGvP5guFovFkhOCEMwCgzhwx1OlHOV1ueDwzgYICsWCtAGooCAGF08ABGPh+zp4ABMfD4UkkrDZUE67HYqNc7k8Pj8ARxLxVGj01BoGEq4iAA)

[Typescript 4.0 (does not work any more)](https://www.typescriptlang.org/play?ts=4.0.5#code/C4TwDgpgBAyglgOwNYB4AqA+KBeKAKYALigQFcBbAIwgCcAaKMAQxABsB7JgE2LQEocWAG7s4XANwAoSaEhQACjXZdSAY1rosuAsTJVaDAM6IkxeMk0Dsw0ROmzoAUQAewGk1XAAwuwTAIfuhQEK4BXIZQANqKymoapMgI7ADuCBgMAHRZMSrqNCgJSEmpGJEAumVaUADeklD1UUhQiFBIECDsAGZQaGW8kUhlwaEI4QpKuRqInbRQAKpYAPzzULoQQrRSAL7SnQmecL5QquxUiBAA6nDAABZBIf6jEdETcfmFxWmZ2a95BYkpNLlMoMBZ4OoNToIYh4LIZJg0ADmhmILjcHm8vkewEsgnmdAh9ThhnYpBo6hRPUkfGIOTeKAWNUJUBoEGAZIQUASXAgnXOXCgTAiTAQIG2u32wEOnK6mjw0J6NPGsT+mCZDRZbI5XNGvP5guFovFkhOCEMwCgzhwx1OlHOV1ueDwzgYICsWCtAGooCAGF08ABGPh+zp4ABMfD4UkkrDZUE67HYqNc7k8Pj8ARxLxVGj01BoGEq4iAA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
type Sink<T> = (t: number, payload: T) => void;

type Producer<T> = (t: number, sink: Sink<T>) => void;

type ExtractContent<T extends [Producer<unknown>, ...Producer<unknown>[]]> = {
    [k in keyof T]: T[k] extends Producer<infer U> ? U : never;
}

function combineWith<T extends [Producer<unknown>, ...Producer<unknown>[]], U>(
    fn: (...args: ExtractContent<T>) => U,
    ...sources: T
): Producer<U> {
    return undefined as any;
}

function of<T>(n: T): Producer<T> {
    return undefined as any;
}

const x = combineWith((x, y) => x + y, of(1), of(2));
```
With typescript 3.9, the arguments of the lambda passed to combineWith are correctly read as `(number, number)`. With 4.0 everything is just `unknown`, even the `Producer` arguments later

### 🙁 Actual behavior

x and y (of the lambda function) are types `unknown`

### 🙂 Expected behavior

x and y (of the lambda function) are types `number`
Repository: rust
Issue: Error in trait solving
Labels: A-diagnostics,T-compiler,D-confusing

Related to https://github.com/rust-lang/rust/issues/78113. In the following example the trait system cannot resolve the trait object `A` in `Box<dyn A + 'a>` to Foo, even though Foo implements A:

```
#![feature(generic_associated_types)]

trait A {}

struct Foo {}

impl A for Foo {}

impl<'a> A for &'a Box<dyn A + 'a> {}

trait X {
  type T<'a> : A;
}

struct B {}

impl X for B {
  type T<'a> = &'a Box<dyn A + 'a>;
}

impl B {
  fn foo<'a>(&self, arg : &'a Box<Foo>) -> <Self as X>::T<'a> {
    arg
  }

}

fn main() {}
```

This yields the error: 

```
error[E0308]: mismatched types
  --> /Users/bn/Documents/Rust/rust_error_samples/gat_type_alias_lifetime.rs:23:5
   |
23 |     arg
   |     ^^^ expected trait object `dyn A`, found struct `Foo`
   |
   = note: expected reference `&'a Box<(dyn A + 'a)>`
              found reference `&'a Box<Foo>`

error: aborting due to previous error; 1 warning emitted
```

If we don't provide a lifetime bound in the implementation of A for `&'a Box<dyn A>` (`impl<'a> A for &'a Box<dyn A>`) then we get an additional lifetime error since this trait impl is resolved to `impl<'a> A for &'a Box<dyn A + 'static>`, resulting in two errors:

```
error[E0308]: mismatched types
  --> /Users/bn/Documents/Rust/rust_error_samples/gat_type_alias_lifetime.rs:18:3
   |
18 |   type T<'a> = &'a Box<dyn A + 'a>;
   |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime mismatch
   |
   = note: expected trait `A`
              found trait `A`
note: the lifetime `'a` as defined on the associated item at 18:10...
  --> /Users/bn/Documents/Rust/rust_error_samples/gat_type_alias_lifetime.rs:18:10
   |
18 |   type T<'a> = &'a Box<dyn A + 'a>;
   |          ^^
   = note: ...does not necessarily outlive the static lifetime

error[E0308]: mismatched types
  --> /Users/bn/Documents/Rust/rust_error_samples/gat_type_alias_lifetime.rs:23:5
   |
23 |     arg
   |     ^^^ expected trait object `dyn A`, found struct `Foo`
   |
   = note: expected reference `&'a Box<(dyn A + 'a)>`
              found reference `&'a Box<Foo>`

error: aborting due to 2 previous errors; 1 warning emitted
```
Repository: pytorch
Issue: Make use of eps for numerical stability more consistent
Labels: module: numerical-stability,triaged

Different ops have `eps` as argument to ensure numerical stability when dividing by Tensors that can be 0.
In general, we should handle these epsilon consistently as discussed in https://github.com/pytorch/pytorch/pull/49807#discussion_r554097359

While some paper explicitly say that we should use `val + eps`  (like batchnorm and other normalizations).
We should fix the other ones to use clamping to avoid unnecessary changes of the values far from 0.

In particular, we should check the following functions:
- cosine similarity
- norms
- cdist
Repository: create-react-app
Issue: Add support for typescript transformers
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

I would like to include [typescript-is](https://github.com/woutervh-/typescript-is) in my project which requires TypeScript transformer.

### Describe the solution you'd like

Typescript transformers should work out of the box.

### Describe alternatives you've considered

Currently the only option seems to be ejecting the application and modifying webpack config manually.
Repository: go
Issue: runtime: TestCallbackInAnotherThread timeout on windows-arm-zx2c4
Labels: OS-Windows,NeedsInvestigation,compiler/runtime

[2021-01-08T16:28:15-32afcc9/windows-arm-zx2c4](https://build.golang.org/log/c33e76d9da531b0bb53be2642e52563f21ab3e3a)

```
--- FAIL: TestCallbackInAnotherThread (0.10s)
    syscall_windows_test.go:272: timeout waiting for thread to exit
FAIL
FAIL	runtime	78.795s
```

The test hard-codes a 100ms timeout on the call:
https://github.com/golang/go/blob/f1980efb92c011eab71aa61b68ccf58d845d1de7/src/runtime/syscall_windows_test.go#L268

It's not clear to me whether the hard-coded timeout is correct — 100ms seems like a long time, but is it possible for the builder to naturally stall for that long, say, loading the `CreateThread` function from the DLL?

CC @alexbrainman @zx2c4 @bradfitz
Repository: flutter
Issue: NestedScrollView extreme scroll jank with BouncingScrollPhysics
Labels: framework,c: performance,f: scrolling,has reproducible steps,P2,team-framework,triaged-framework,found in release: 3.16,found in release: 3.19

NestedScrollView with BouncingScrollPhysics (or running on iOS) exhibits considerable scroll jank with slight movements, including full height toggles.

https://gist.github.com/lukepighetti/36d228fda97b145c6648365f6bcc8d0e#file-nested_scroll_view-dart

Here's a video showing the jank from another project. https://www.youtube.com/watch?v=f5cQ-SHwYbs&feature=youtu.be


**Expected results:** <!-- what did you want to see? -->

Smooth scrolling / no jank.

**Actual results:** <!-- what did you see? -->

Jank.

<details>
  <summary>Logs</summary>

<!--
      Run your application with `flutter run --verbose` and attach all the
      log output below between the lines with the backticks. If there is an
      exception, please see if the error message includes enough information
      to explain how to solve the issue.
-->

```
```

<!--
     Run `flutter analyze` and attach any output of that command below.
     If there are any analysis errors, try resolving them before filing this issue.
-->

```
```

<!-- Finally, paste the output of running `flutter doctor -v` here. -->

```
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, 1.25.0-8.2.pre, on Mac OS X 10.15.7 19H2 darwin-x64,
    locale en-US)
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 12.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 4.1)
[✓] VS Code (version 1.52.1)
[✓] Connected device (1 available)
    ! Error: Luke's iPhone is not connected. Xcode will continue when Luke's
      iPhone is connected. (code -13)

• No issues found!
```

</details>
Repository: go
Issue: runtime: heap, allocs, block, and mutex profiles truncate stacks at 32 frames
Labels: NeedsDecision,compiler/runtime

The runtime currently (as of Go 1.15) limits recorded stacks of several profile types to 32 frames. This causes deep stacks to become unrooted in pprof call graphs, leading to confusing results and interfering with aggregate statistics up the call graph.

These are hard-coded array bounds in the public runtime API for [StackRecord](https://pkg.go.dev/runtime#StackRecord) (used in BlockProfileRecord) and [MemProfileRecord](https://pkg.go.dev/runtime#MemProfileRecord). Unfortunately, this means these are part of the Go 1 runtime API, so we can't just change them. If we were to increase them, this would impact memory for relatively little gain, since stacks typically aren't this deep. Finally, we probably need some reasonable bound on stack depth just to avoid blowing up profiles.

The "right" fix, in my opinion, is to do what we did with CPU profiles: deprecate the runtime package interface in favor of runtime/pprof, create a log-based back channel from runtime to runtime/pprof that can handle variable-sized stack traces, and perform accumulation in runtime/pprof. That's quite a bit of engineering for a fairly obscure problem, though it would also help with labeling non-CPU profiles (#23458).

We don't have plans to fix this right now. This is just a tracking issue.
Repository: create-react-app
Issue: When default BROWSER is modified, produces an error in docker
Labels: needs triage,issue: bug report

### Describe the bug

When `yarn start` finishes successfully, it automatically opens Chrome browser and shows running app. If you want to change this behaviour, official CRA docs says to override `BROWSER` environment variable to your desired browser, before the `yarn start` command execution. It works flawlessly. With docker, after it does `yarn start` inside container, it gives an error because is trying to execute Opera browser, which is obviously not possible. And if you try the same without `BROWSER=opera`, it's working fine. 

This is why I think it's a bug, because seems that `react-scripts start` check if it is in a headless system and not triggers the browser, but if you overrides BROWSER env var, it doesn't check.

### Environment

  current version of create-react-app: 4.0.0
  running from /Users/user/.config/yarn/global/node_modules/create-react-app

  System:
    OS: macOS 10.15.6
    CPU: (8) x64 Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
  Binaries:
    Node: 14.15.0 - ~/.nvm/versions/node/v14.15.0/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 6.14.8 - ~/.nvm/versions/node/v14.15.0/bin/npm
  Browsers:
    Chrome: 87.0.4280.141
    Edge: 87.0.664.75
    Firefox: 83.0
    Safari: 13.1.2
  npmPackages:
    react: 17.0.1 => 17.0.1 (16.14.0)
    react-dom: 17.0.1 => 17.0.1 (16.14.0)
    react-scripts: 4.0.1 => 4.0.1 
  npmGlobalPackages:
    create-react-app: Not Found
### Steps to reproduce

1. Fresh create-react-app install.
2. Create a .env with `BROWSER=opera` inside
2. Command `yarn start` -> OK
3. Dockerizating app with simple `Dockerfile`:
```
# base image
FROM node:14.15-slim
# set working directory
WORKDIR /app
# copy package.json and lock to ensure correct versions
COPY package.json yarn.lock ./
# install node modules
RUN yarn --non-interactive --frozen-lockfile
# add app to container
COPY . /app
# start app in dev mode
CMD yarn start
```
4. Running the docker
5. Error
```
 Starting the development server...
events.js:292
throw er; // Unhandled 'error' event
^
Error: spawn opera ENOENT
     at Process.ChildProcess._handle.onexit (internal/child_process.js:269:19)
     at onErrorNT (internal/child_process.js:465:16)
     at processTicksAndRejections (internal/process/task_queues.js:80:21)
 Emitted 'error' event on ChildProcess instance at:
     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
     at onErrorNT (internal/child_process.js:465:16)
     at processTicksAndRejections (internal/process/task_queues.js:80:21) {
   errno: -2,
   code: 'ENOENT',
   syscall: 'spawn opera',
   path: 'opera',
...
```