sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Order destructuring Iterable<keyof T> changed from 3.2.4 -> 3.4.x
Labels: Bug

In 3.2.4, destructuring a value whose type is the intersection of `Pick<T, keyof T> & Iterable<T[keyof T]>` inferred types at assignment whose order followed the `keyof T` order. In 3.4.x and above it seems the `keyof T` order isn't respected at assignment, but is inferred correctly later. Screenshots attached below.

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.4.3 and 3.5.0-dev.20190413

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
iterable iterator generic type parameter keyof order intellisense

**Code**
```ts
type Row<T extends { [key: string]: any }> =
    { [P in keyof T]: T[P] }
    &
    ( Iterable<T[keyof T]> )

type Schema = {
    0: number;
    1: string;
}

let row: Row<Schema> = [123, 'foo']

let a = row[0] // number
let b = row[1] // string

// c and d are each string | number
let [c, d] = row

let x = c // x is correctly inferred to be number
let y = d // y is correctly inferred to be string
```

**Expected behavior:**
`c` and `d` types are `number` and `string` at assignment, respectively.

**Actual behavior:**
`c` and `d` are each `string | number` at assignment.

**Screenshots:**
typescript@3.2.4:
![Screenshot from 2019-04-15 21-30-40](https://user-images.githubusercontent.com/178183/56182213-eebbec80-5fc5-11e9-9a5f-627bd26af6d3.png)

typescript@3.5.0-dev.20190413:
![Screenshot from 2019-04-15 21-31-02](https://user-images.githubusercontent.com/178183/56182227-fbd8db80-5fc5-11e9-8828-4ceedfe758f1.png)

![Screenshot from 2019-04-15 21-31-14](https://user-images.githubusercontent.com/178183/56182228-fed3cc00-5fc5-11e9-8988-9333c6fd69b9.png)

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
Doesn't show the bug because there's no option to enable `--downlevelIteration`, but here's a link:
https://www.typescriptlang.org/play/index.html#src=type%20Row%3CT%20extends%20%7B%20%5Bkey%3A%20string%5D%3A%20any%20%7D%3E%20%3D%0D%0A%20%20%20%20%7B%20%5BP%20in%20keyof%20T%5D%3A%20T%5BP%5D%20%7D%0D%0A%20%20%20%20%26%0D%0A%20%20%20%20(%20Iterable%3CT%5Bkeyof%20T%5D%3E%20)%0D%0A%0D%0Atype%20Schema%20%3D%20%7B%0D%0A%20%20%20%200%3A%20number%3B%0D%0A%20%20%20%201%3A%20string%3B%0D%0A%7D%0D%0A%0D%0Alet%20row%3A%20Row%3CSchema%3E%20%3D%20%5B123%2C%20'foo'%5D%0D%0A%0D%0Alet%20a%20%3D%20row%5B0%5D%20%2F%2F%20number%0D%0Alet%20b%20%3D%20row%5B1%5D%20%2F%2F%20string%0D%0A%0D%0A%2F%2F%20c%20and%20d%20are%20each%20string%20%7C%20number%0D%0Alet%20%5Bc%2C%20d%5D%20%3D%20row%0D%0A%0D%0Alet%20x%20%3D%20c%20%2F%2F%20x%20is%20correctly%20inferred%20to%20be%20number%0D%0Alet%20y%20%3D%20d%20%2F%2F%20y%20is%20correctly%20inferred%20to%20be%20string%0D%0A
Repository: TypeScript
Issue: Alias for TypeScript declaration emitting
Labels: Suggestion,Awaiting More Feedback

## Search Terms

* alias
* declaration

## Suggestion

A way to configuration alias for declaration files. 

## Use Cases

Related: #10866

I understand that TypeScript team want to leaves module resolving for other tools like Webpack. However, most of the tools are focus on emitting JavaScript. If you want to emit TypeScript declaration, you need to use `tsc`.

This is important when you want to write library with TypeScript that you need to release declaration files.

For example, in Webpack, `babel-loader` does not emit declarations, `ts-loader` and `awesome-typescript-loader` uses `tsc`.

Alias is useful for you to write simpler import / export statement.

## Examples

**index.ts**
```ts
export * from "~/foo";
```

**index.d.ts**
```ts
export * from "../../foo";
```

**tsconfig.json**
```json
{
  "alias": {
    "~/*": ["src/*"]
  }
}
```

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: TypeScript
Issue: TypeScript not enforcing the return type of optional methods defined in interfaces implemented by parents of classes
Labels: Bug

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.5.0 (Also tried 3.4.1, 3.0.1, and 2.4.1)

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** Inheritance, interface, return type, parent, child, override, overload, abstract, optional method, optional interface, implements, extends

**Code**

```ts
interface Mx {
  aMethod?(): number;
}

abstract class Base implements Mx {

}

class Child extends Base {
  public aMethod() {
    return 'hello world';
  }
}
```

**Expected behavior:**
TypeScript tells me that the return type for `Child#aMethod` is wrong.

This behaviour is achieved if I add `implements Mx` on the `Child` class. 

**Actual behavior:**
TypeScript tells me nothing! It feels that `Child#aMethod` is well within its rights to return a string.

**Playground Link:** [linky!](https://www.typescriptlang.org/play/#src=interface%20Mx%20%7B%0D%0A%20%20aMethod%3F()%3A%20number%3B%0D%0A%7D%0D%0A%0D%0Aabstract%20class%20Base%20implements%20Mx%20%7B%0D%0A%0D%0A%7D%0D%0A%0D%0Aclass%20Child%20extends%20Base%20%7B%0D%0A%20%20public%20aMethod()%20%7B%0D%0A%20%20%20%20return%20'hello%20world'%3B%0D%0A%20%20%7D%0D%0A%7D%0D%0A)

**Related Issues:** I didn't really find any similar looking issues?

The result is this could *maybe* relate to #22815
Repository: node
Issue: Crash in wrap_js_stream.js during doClose
Labels: stream

* **Version**: v10.15.3
* **Platform**: Linux zagentXXXX 4.4.0-141-generic #167~14.04.1-Ubuntu SMP Mon Dec 10 13:20:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
* **Subsystem**: net

I've debated whether this belongs in node/help, but due to potential of being a node bug I've decided to post here (apologize in advance if it turns out otherwise).

We have a crash happening on our production servers a few times a day (especially during high load times):
```
TypeError: Cannot read property 'finishWrite' of null
    at JSStreamWrap.finishWrite (internal/wrap_js_stream.js:195:12)
    at Immediate.setImmediate (internal/wrap_js_stream.js:218:12)
    at runCallback (timers.js:705:18)
    at tryOnImmediate (timers.js:676:5)
    at processImmediate (timers.js:658:5)
```
I was unable to see any possible code path that could cause `this._handle` to be null before the call to `doClose` as it's only triggered by calling `this._handle.close()`.
Async paths printing would have come very useful here, however, this is node 10.x.

I've done grep on all our code as well as all node-modules for anything that could relate to 'games' with `"_handle = "` or `doClose`, nothing pop'ed up.

I've put DEBUG_NODE=net,stream_wrap on one of the servers to avoid overall network degradation (waiting for crash to re-occur).

Note: server is a large traffic networking proxy application involving http/s/2.

I would like to give more info (specifically `setImmediate` async callstack), however, I'm unsure how to continue, would appreciate any advice.
Repository: opencv
Issue: ncurses.h incompatibility
Labels: category: build/install,future,category: 3rdparty

##### System information (version)

- OpenCV => 3.4
- Operating System / Platform => openSUSE Tumbleweed
- Compiler => gcc8-c++

##### Detailed description


Incompatibility with ncurses.
I was using opencv2 on Debian, and today I moved to openSUSE Tumbleweed, which has opencv3, and my first make failed with this error (see attached file).


##### Steps to reproduce

If ncurses.h is included before opencv headers, build breaks.
Workaround: `#include <opencv2/opencv.hpp>` before `#include <ncurses.h>`

[opencv-ncurses_incompatibility.txt](https://github.com/opencv/opencv/files/3085377/opencv-ncurses_incompatibility.txt)
Repository: go
Issue: x/text/transform: errInconsistentByteCount should be returned by too big nSrc
Labels: NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/yuki/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/yuki/.local/share/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/yuki/.local/src/golang.org/x/text/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build370827352=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->

```go
package main

import (
	"bytes"

	"golang.org/x/text/transform"
)

type T struct{ transform.NopResetter }

func (*T) Transform(dst, src []byte, atEOF bool) (nDst, nSrc int, err error) {
	return 0, 4, transform.ErrShortDst
}

func main() {
	buf := make([]byte, 3)
	fmt.Println(transform.NewReader(bytes.NewReader([]byte("abc")), &T{}).Read(buf))
}
```

The point is that the `Transform()` returns invalid `nSrc`.

### What did you expect to see?

The `Read()` should return `transform.errInconsistentByteCount` because the `Transform()` returns invalid `nSrc`(`nSrc > len(src)`). The code comment says

> errInconsistentByteCount means that Transform returned success (nil error) but also returned nSrc inconsistent with the src argument.

The error is suitable for this case.

### What did you see instead?

It panics with `slice bounds out of range`.

```
panic: runtime error: slice bounds out of range

goroutine 1 [running]:
golang.org/x/text/transform.(*Reader).Read(0xc00003c700, 0xc00003c6dd, 0x3, 0x3, 0x0, 0xe0c843aa8a3c7960, 0xc00003c6f0)
        /home/yuki/.local/src/golang.org/x/text/transform/transform.go:166 +0x622
main.main()
        /home/yuki/.local/src/golang.org/x/text/transform/test/main.go:17 +0x20e
exit status 2
```

The stack trace points the internal of the library, not the implementation of Transformer. This behavior makes difficult to debug because the real problem is in the use of transform package, but the error doesn't suggest that.
Repository: vscode
Issue: [folding] selecting first line of folded range does not select full folded range
Labels: feature-request,editor-folding

Issue Type: <b>Bug</b>

1. Create a variable with an array
2. Collapse the array
3. Mark the line with the array and copy it
5. Paste below

**Actual result:**
the only array name with open bracket is copied

**Expected result:**
whole array is copied

**PFA**


VS Code version: Code 1.33.1 (51b0b28134d51361cf996d2f0a1c698247aeabd8, 2019-04-11T08:20:22.771Z)
OS version: Linux x64 4.15.0-47-generic

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz (4 x 3708)|
|GPU Status|2d_canvas: disabled_software<br>checker_imaging: disabled_off<br>flash_3d: disabled_software<br>flash_stage3d: disabled_software<br>flash_stage3d_baseline: disabled_software<br>gpu_compositing: disabled_software<br>multiple_raster_threads: disabled_off<br>native_gpu_memory_buffers: disabled_software<br>rasterization: disabled_software<br>surface_synchronization: disabled_off<br>video_decode: disabled_software<br>webgl: disabled_off<br>webgl2: disabled_off|
|Load (avg)|0, 1, 1|
|Memory (System)|31.35GB (12.71GB free)|
|Process Argv|--unity-launch|
|Screen Reader|no|
|VM|0%|

</details><details><summary>Extensions (40)</summary>

Extension|Author (truncated)|Version
---|---|---
output-colorizer|IBM|0.1.2
pgformatter|bra|1.6.5
better-toml|bun|0.3.2
npm-intellisense|chr|1.3.0
path-intellisense|chr|1.4.2
bracket-pair-colorizer|Coe|1.0.61
systemd-unit-file|coo|1.0.3
vscode-markdownlint|Dav|0.26.0
vscode-eslint|dba|1.8.2
pgsql|dou|0.1.3
gitlens|eam|9.6.0
tslint|eg2|1.0.43
vscode-npm-script|eg2|0.3.5
LogFileHighlighter|emi|2.4.3
vsc-material-theme|Equ|2.8.2
vscode-postman|eri|0.5.2
gauge|get|0.0.3
gc-excelviewer|Gra|2.1.32
vscode-nginx-conf-hint|han|0.1.0
beautify|Hoo|1.4.11
js-test-gen-vscode|jsT|0.5.0
ldif|jta|0.1.1
vscode-regexp-preivew|le0|0.0.3
terraform|mau|1.3.9
git-graph|mhu|1.4.5
Go|ms-|0.9.2
sqltools|mtx|0.17.15
makefiles-support-for-vscode|nae|0.0.3
vscode-json-transform|oct|0.1.2
vscode-docker|Pet|0.6.1
vscode-versionlens|pfl|0.22.0
vscode-yaml|red|0.4.0
vscode-sort-json|ric|1.13.0
vscode-statusbar-json-path|ric|1.2.0
monitor-file|rko|1.0.1
sql-snippets|sad|0.0.4
vscode-sql-beautify|sen|0.0.4
slim|sia|0.1.2
language-stylus|sys|1.11.0
vscode-ansible|vsc|0.5.2

(3 theme extensions excluded)

</details>
<!-- generated by issue reporter -->
[collapsed_array_issue-2019-04-16_18.06.33.mp4.zip](https://github.com/Microsoft/vscode/files/3085612/collapsed_array_issue-2019-04-16_18.06.33.mp4.zip)
Repository: flutter
Issue: Camera plugin do not save images from rear camera
Labels: p: camera,a: images,package,team-ecosystem,P2,triaged-ecosystem

I'm building the app which takes photos and using the Camera plugin. The images from front camera are saved and displayed. The images from the rear camera are saved, but not displayed. 

To reproduce it you may use the example app connected with the plugin:
https://github.com/flutter/plugins/tree/master/packages/camera/example

- when I choose front camera and take a picture it shows the url of the image and shows the thumbnail
- when I choose rear camera and take a picture it shows the url of the image, but do not shows the thumbnail

No error message or exception is displayed.

I'm doing it on Samsung Galaxy J5 with Android 7.1.1.
Repository: flutter
Issue: Feature Request: Add minLines to Text (Not TextField)
Labels: c: new feature,framework,P3,team-framework,triaged-framework

I've seen many requests from other user to add minLines into **TextField**. But please also add it for **Text**. Thanks
Repository: TypeScript
Issue: JSDoc multi-line properties within Array<Object> syntax parse differently than Object[]
Labels: Bug

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.5.0-dev.20190416

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
JSDoc @type @param @arg multi-line type literal Array<>

**Code**

```ts
/**
 * @param {Array<Object>} os - has a string and a number
 * @param {string} os[].s - the string
 * @param {number} os[].n - the number
 */
function f(os) { return os[0].s; }
```

**Expected behavior:**

It appears that #17352 implemented this correctly for when the first `@param` is `@param {Object[]}` but failed to consider the other syntax to write this in JSDoc: `@param {Array<Object>}`.

For ease of debugging I am looking at the output of Intellisense when hovering over `os` in the function. I'd expect the output to look as iti does when `@param {Object[]}` is used: 
![image](https://user-images.githubusercontent.com/6043371/56229963-29b33400-6049-11e9-9d83-6e42c34491a9.png)

**Actual behavior:**
![image](https://user-images.githubusercontent.com/6043371/56229980-346dc900-6049-11e9-86f8-b1b4f3a576bc.png)

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
[Playground Link](https://www.typescriptlang.org/play/#src=%2F**%0D%0A%20*%20%40param%20%7BArray%3CObject%3E%7D%20os%20-%20has%20a%20string%20and%20a%20number%0D%0A%20*%20%40param%20%7Bstring%7D%20os%5B%5D.s%20-%20the%20string%0D%0A%20*%20%40param%20%7Bnumber%7D%20os%5B%5D.n%20-%20the%20number%0D%0A%20*%2F%0D%0Afunction%20f(os)%20%7B%20return%20os%5B0%5D.s%3B%20%7D)

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
#11597
Repository: go
Issue: cmd/compile: additional internal debugging support for escape.go
Labels: NeedsInvestigation,compiler/runtime

esc.go and escape.go both support -m=1 for emitting diagnostics about escape analysis results, but esc.go additionally supported -m=2 and above for emitting diagnostics about internal code execution and decision making. escape.go should provide similar functionality for compiler maintainer use.
Repository: go
Issue: net: KeepAlive is disabled by write to dead link
Labels: Documentation,NeedsInvestigation

 _Was: net.Dialer.Dial() doesn't respect .KeepAlive_

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.12 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Haven't tried 1.12.1+

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/root/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build601953146=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do/see?

For a TLS connection that's been dropped, c.Read() returns a net.Error with `e.Timeout()==true` after ~18 minutes, apparently due to KeepAlive failure. The connection is closed by the server while the client (laptop running VMWare with Linux) is suspended. Error string:
"read tcp n.n.n.n:p->n.n.n.n:p: read: connection timed out"


The note on https://github.com/golang/go/commit/5bd7e9c5 (discussed in #23459) says the default for net.Dialer keepalive failure is just 2-3min. With an explicit KeepAlive, I also see odd waits:

 `net.Dialer{KeepAlive: 30 * time.Second}` 18min
 `net.Dialer{KeepAlive: 25 * time.Second}` 18min
 `net.Dialer{KeepAlive: 10 * time.Second}` 16min
 `net.Dialer{KeepAlive:  5 * time.Second}` <1min, but at least once 18min

Measurements aren't precise; 16-18 minutes could be 1000 or 1024 seconds. Code has:
```
   aDlr := net.Dialer{Timeout: 3*time.Second} // default KeepAlive
   aCfgTls := tls.Config{InsecureSkipVerify: true}
   aConn, err := tls.DialWithDialer(&aDlr, "tcp", "host:port", &aCfgTls)
   if err != nil { return err }
   err = aConn.Write(...) // <256 bytes
   // brief exchange of short messages
   aLen, err := aConn.Read(...)
```

Also filed #31449 to report that the error due to keepalive doesn't comply with the docs re connection timeout.

cc @FiloSottile @bradfitz
Repository: godot
Issue: Children list of inherited scene doesn't update after add/delete nodes in parent scene
Labels: bug,topic:editor,confirmed

**Godot version:**
3.1 stable

**OS/device including version:**
Windows 7 x64

**Prerequisites:**
1. Create scene 1 - "Level",
2. Create scene 2 - "Parent",
3. Create scene 3 - "Something" as "New inherited scene" of "Parent"

**Steps to reproduce:**
1. In "Level" scene make instance of "Something",
2. Set "Editable children" is ON,
3. Add one or more child nodes in "Parent" scene and save this scene,
4. Go back to "Level" scene tab

**Result:**
Created nodes in step 3 are not shown. They will appear only if you close and re-open "Level".
Meanwhile, if you change tab to "something" you will see new nodes imediately.

**Note:** same result if you delete node in step 3

**Expected:**
Nodes list updated imediately, don't need to re-open tab to see changes.

**GIF:**
![bug16042019](https://user-images.githubusercontent.com/1552169/56231884-2d19e000-6088-11e9-8646-c7ea45ee86ce.gif)

**Minimal reproduction project:**
This project contains only prerequesites. You should open all three scenes and repeat 3-4 steps.
[test16042019.zip](https://github.com/godotengine/godot/files/3086184/test16042019.zip)
Repository: create-react-app
Issue: CRA sourcemaps do not conform to the specification
Labels: issue: needs investigation

### Is this a bug report?

Yes

### Did you try recovering your dependencies?

No

### Which terms did you search for in User Guide?

sourcemap

### Environment

Observed in several different environments

### Steps to Reproduce

1. Create an app with `create-react-app`
2. start the dev-server
3. look at the `sources` array in the sourcemaps served by the dev-server

### Expected Behavior

The `sources` array should contain URLs according to [the spec](https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#heading=h.75yo6yoyk7x5)

### Actual Behavior

The `sources` array contains absolute file paths


I noticed this problem when I tried to figure out why my [debug adapter for VS Code](https://marketplace.visualstudio.com/items?itemName=hbenl.vscode-firefox-debug) didn't work out-of-the-box with CRA projects. The reason was that my debug adapter treats the entries in the `sources` array in the sourcemap exactly like the spec says it should: it checks if an entry is an absolute URL (which it isn't) and then resolves it relative to the sourcemap. It then ends up with something like `http://localhost:3000/c:/Users/user/...` on Windows or `http://localhost:3000/home/user/...` on Linux, and these URLs don't make sense.
The workaround is to treat entries that _look like_ an absolute path as paths instead of URLs. The problem with this workaround is that it will break sourcemaps that contain root-relative URLs (i.e. relative URLs that start with `/`) because on Mac and Linux these look like absolute paths.

The fix for this would be simple: add `file://` (or `file:///` on Windows) to the paths and they becoma URLs. Alternatively, you could simply set `sourceRoot` to `file://` because that is supposed to be prepended to the `sources`.