sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: next.js
Issue: .js file extension not recognized in bundler for Typescript files
Labels: bug,TypeScript,linear: next

### Link to the code that reproduces this issue

https://codesandbox.io/p/devbox/affectionate-satoshi-xk5gqp

### To Reproduce

1. Import a Typescript source file using the `.js` file extension required to conform with ES Modules syntax
2. `next build`
3. See error about "module not found"

### Current vs. Expected behavior

- in order to write fully valid ES Module code, you are currently supposed to specify the file extension of the file you are importing
- Typescript decided that the file extension of a .ts import should be ".js" to reflect runtime import behaviour, so the current recommendation is to import Typescript files with `.js` extension in a project that must conform to ES modules spec (namely to run in Node properly)

current:
- following recommended import syntax results in a "module not found" error

expected:
- next should correctly resolve these imports



### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
Binaries:
  Node: 20.9.0
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: 8.10.2
Relevant Packages:
  next: 14.0.5-canary.17
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A


Done in 2.28s.
```


### Which area(s) are affected? (Select all that apply)

App Router, TypeScript (plugin, built-in types)

### Additional context

This is the same problem as reported in this issue:
https://github.com/vercel/next.js/issues/33056

which was closed as being a duplicate of a "discussion":
https://github.com/vercel/next.js/discussions/32237

re-opening it as an issue since it's a bug in the build system that should be fixed

Some additional challenges with this:
- ES module 3rd party libraries that are imported into Next JS and used in Page router server functions like `getServerSideProps` are subject to working properly in the Node ESM resolver since that's what the Pages build system is using
- this means that those libraries must have `.js` extensions present in their source files in order to work correctly in Next
- the same restriction does not appear to apply to code imported in App Router, which I guess uses a different ESM resolver other than Node's. Files work either with or without that extension in 3rd party libs
- it's confusing when developing a Next library that the code _must_ include `.js` extensions in order to work, while currently any application code _must not_ include those extensions in order to work. It should work in both places.
- the `.js` extension isn't recognized in either App Router or Pages Router for serverside code

<sub>[NEXT-2779](https://linear.app/vercel/issue/NEXT-2779/js-file-extension-not-recognized-in-bundler-for-typescript-files)</sub>
Repository: puppeteer
Issue: [Bug]: node_modules/puppeteer/lib/types.d.ts(601,10): error TS2748: Cannot access ambient const enums when 'isolatedModules' is enabled.
Labels: feature

### Minimal, reproducible example

```TypeScript
Use puppeteer in a TS project with `isolatedModules` enabled.
```


### Error string

error TS2748: Cannot access ambient const enums when 'isolatedModules' is enabled.

### Bug behavior

- [ ] Flaky
- [ ] PDF

### Background

https://www.typescriptlang.org/docs/handbook/enums.html#const-enum-pitfalls

possibly could be solved by using `preserveConstEnums` and stripping the `const` from the generated d.ts as suggested in the possible fixes

### Expectation

It should be possible to use puppeteer in a project with `isolatedModules`

### Reality

Compile errors

### Puppeteer configuration file (if used)

_No response_

### Puppeteer version

21.6.1

### Node version

21.2.0

### Package manager

npm

### Package manager version

10.2.3

### Operating system

macOS
Repository: angular
Issue: Cannot use $localize or i18n-attribute for [input] attributes
Labels: area: i18n

### Which @angular/* package(s) are relevant/related to the feature request?

localize

### Description

When we have attributes to localize like `<input placeholder="Name">` we can do it with `<input i18n-placeholder placeholder="Name">`.
When we have strings in component code, we can do 
```
var Name = $localize `James Bond`;`
```

But, there is no solution to when we have `<input [placeholder]="'Meeting with '+ {{Name}}">`

### Proposed solution

Either allow `i18n-placeholder`, or `i18n-[placeholder]` or
```
<input [placeholder]="$localize `Meeting with ` + {{Name}}">
```

### Alternatives considered

I tried  `i18n-placeholder` but it doesn't extract anything.
I tried `i18n-[placeholder]` but it doesn't extract anything.
I tried 
```
<input [placeholder]="$localize `Meeting with ` + {{Name}}">
```
but it throws an error 
```
Parser Error: Unexpected token 'Lexer Error: Unexpected character [`]
```
Repository: godot
Issue: Replacing a node with an instantiated scene via replace_by causes the replacement to lose scene_file_path
Labels: discussion,topic:core,documentation

### Tested versions

- Reproducible in: v4.3.dev.custom_build [d76c1d0e5], 4.2.1.stable, 4.2.stable, 4.1.3.stable.
- Not reproducible in: none found (did not test versions before 4.1.3.stable).

### System information

Godot v4.3.dev (d76c1d0e5) - Manjaro Linux #1 SMP PREEMPT_DYNAMIC Thu Dec 14 00:46:56 UTC 2023 - X11 - Vulkan (Forward+) - integrated AMD Radeon Vega 10 Graphics (RADV RAVEN) () - AMD Ryzen 7 3750H with Radeon Vega Mobile Gfx (8 Threads)

### Issue description

I ran into this issue while writing an EditorScenePostImport script:

Suppose `y` is an instance of a scene.

Running `x.replace_by(y)` sets `y.scene_file_path` ~~to `""`~~ to `x.scene_file_path`.

Consequently, if `x` was a descendant of a node that will be saved as scene `S`, then `y`'s inherited children will not be shown in the editor in scene `S`. (They can still be accessed with `$'y'.get_children()`.)

If we then instantiate scene `S` to create inherited scene `T`, then the `y` which `T` inherits from `S` will not have its inherited children at all. (They cannot even be accessed with `$'y'.get_children(true)`.)

### Steps to reproduce

To use the MRP:
- Open `A.tscn` in the editor.
- Run `EditorScript` `control_group.gd`, which uses `remove_child` and `add_child`. Observe the behavior is as desired (i.e. `$'A/E'` is marked as a scene instance, and if we enable editable children or make it local, its children appear).
- Close `A.tscn`. **Do not save it before closing.**
- Reopen `A.tscn`.
- Now run `EditorScript` `issue_repro.gd`, which uses `replace_by`. The issue I've described should then present.

### Minimal reproduction project (MRP)

[repro.zip](https://github.com/godotengine/godot/files/13708507/repro.zip)
Repository: go
Issue: syscall: TestExec failures with SIGSEGV on riscv64
Labels: help wanted,NeedsInvestigation,arch-riscv,compiler/runtime

```
#!watchflakes
post <- goarch == "riscv64" && pkg == "syscall" && test == "TestExec" && `signal: segmentation fault`
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/3c1fffbeb350cfced3e1c52abc275a41a069afc6)):

    --- FAIL: TestExec (1.19s)
        exec_unix_test.go:317: 
            signal: segmentation fault (core dumped)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: ollama
Issue: Add support for Intel Arc GPUs
Labels: feature request,intel
Repository: godot
Issue: Resizing a SubViewportContainer with viewport scaling and expand aspect ratio attempts to render ludicrously large viewports
Labels: bug,topic:core

### Tested versions

4.2.1.stable.arch_linux

### System information

Godot v4.2.1.stable unknown - Arch Linux #1 SMP PREEMPT_DYNAMIC Thu, 14 Dec 2023 03:45:42 +0000 - X11 - Vulkan (Forward+) - dedicated AMD Radeon RX 6700 XT () - AMD Ryzen 9 5900X 12-Core Processor (24 Threads)

### Issue description

when resizing a window containing a full-screen anchored SubViewportContainer with viewport scaling and expand aspect ratio the engine will happily attempt to render an image with resolutions approaching 1152x800000

this is user error, however I think a quick check in viewport resizing code to make sure neither side length exceeds 100k (and crashing with a descriptive error message) would be a good addition to save others the confusion I experienced

### Steps to reproduce

1. create a new project (or open the provided MRP and skip to step 6)
2. go into project settings, set the scaling mode to viewport and aspect ratio to expand
3. create a scene with a root SubViewportContainer and a child SubViewport
4. set the SubViewportContainer's stretch mode on, and anchor it as full rect
5. attach the provided script to the SubViewportContainer to see the size of the control element (and by extension the viewport) and to exit the game without running out of memory (feel free to comment out the line containing the `get_tree().quit()`, but make sure no work would get lost if your entire machine crashes)
6. run the game and resize the window to be narrower or less tall
7. the console log should show an ever increasing number for either the X or Y rendering size, showing the problem, the game should exit the moment either number exceeds 100000, to try to prevent crashing



script:
```
extends Control
func _ready():
	resized.connect(_on_size_changed)
func _on_size_changed():
	print(size)
	if (size.x > 100000 or size.y > 100000):
		get_tree().quit()
```

### Minimal reproduction project (MRP)

[small_project.zip](https://github.com/godotengine/godot/files/13709485/small_project.zip)
Repository: next.js
Issue: `cache: 'no-store'` does not prevent `fetch` during static build
Labels: bug,Pages Router

### Link to the code that reproduces this issue

https://github.com/xixixao/nextjs-cache-no-store

### To Reproduce

1. npm run build

### Current vs. Expected behavior

## What I expect
I expect to get no warnings. I specifically expect to not make a `fetch` during static build which has `cache: 'no-store'` set. This is important because I might be making a push in this sequence:

1. Build my site
2. Deploy my external API service
3. Deploy my site

## What I get

The `fetch` still executes during the static build:
```
TypeError: fetch failed
    at Object.fetch (node:internal/deps/undici/undici:11600:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  cause: Error: getaddrinfo ENOTFOUND does.not.exist.foo.bar.boom
      at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:118:26)
      at GetAddrInfoReqWrap.callbackTrampoline (node:internal/async_hooks:130:17) {
    errno: -3008,
    code: 'ENOTFOUND',
    syscall: 'getaddrinfo',
    hostname: 'does.not.exist.foo.bar.boom'
  }
}
```

This might cause errors on my external API service because the new static build might run an API that the my external service isn't supporting yet.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.1.0: Mon Oct  9 21:27:24 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T6000
Binaries:
  Node: 20.6.1
  npm: 10.1.0
  Yarn: N/A
  pnpm: 8.7.4
Relevant Packages:
  next: 14.0.5-canary.18
  eslint-config-next: 14.0.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router, Data fetching (gS(S)P, getInitialProps)

### Additional context

It seems that in the past this kind of error actually failed the build and that's no longer the case, which is good.
Repository: go
Issue: internal/trace/v2: test timeouts
Labels: NeedsInvestigation,compiler/runtime

```
#!watchflakes
post <- pkg == "internal/trace/v2" && `test timed out`
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/f7914fff5ad927b38bae0225c42d9b21ed58e7db)):

    --- FAIL: TestTraceManyStartStop (0.74s)
        --- FAIL: TestTraceManyStartStop/Default (0.74s)
            exec.go:193: test timed out while running command: /tmp/workdir/go/bin/go run testdata/testprog/many-start-stop.go
            trace_test.go:551: stderr: SIGQUIT: quit
                PC=0x250a4627 m=3 sigcode=0
    
                goroutine 0 gp=0x57406b48 m=3 mp=0x57440b08 [idle]:
                runtime.kevent(0x36, 0x0, 0x0, 0x19f70acc, 0x40, 0x19f70aa4)
                	runtime/sys_openbsd2.go:219 +0x21 fp=0x19f70a68 sp=0x19f70a58 pc=0x80a5541
                runtime.netpoll(0x3478c32f)
    ...
                edi    0x784
                esi    0x57406b48
                ebp    0x19f70a18
                esp    0x19f709fc
                eip    0x250a4627
                eflags 0x207
                cs     0x2b
                fs     0x5b
                gs     0x63
            trace_test.go:553: exit status 2


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: deno
Issue: Allow for unmodified headers and ensure `node:http` compatibility
Labels: ext/fetch

Deno currently automatically enforces lowercase casing and alphabetical order of headers when using any of the following:
- the built-in `Headers` class
- the built-in `fetch` function
- `node:http` request functions (i.e. `http.get()`)

While headers are required to be lowercase according to the HTTP/2+ specs, there's no such requirement in the HTTP/1.1 spec. Some browsers, like Firefox and Chrome, actually enforce Pascal-Case headers when using HTTP/1.1. Therefore it's sometimes necessary to ensure unmodified header casing and order:
- some bot detection services evaluate header casing and order to determine whether a connecting client is an actual web browser
- some outdated servers may expect a certain header casing or header order to work properly

The current behavior of the above-mentioned functions and classes is unexpected and unnecessarily excludes certain use cases which require case-sensitive and/or ordered headers. Furthermore, `node:http` is not compliant with node's built-in `http` module, since the latter does not enforce header casing or order.

**Suggestions:**

1. Add an option to `Deno.createHTTPClient` to disable any header modifications (where not required by spec, i.e. lowercase casing when using HTTP/2+)
2. Do not enforce casing or order in the `Headers` class (similar to node) **or** provide a way to ensure headers aren't modified (for example a `RawHeaders` class)
4. Ensure `node:http` behaves similarly to node's `http` module
Repository: deno
Issue: Writable Stream API is Broken for Stdout and Stderr (Async IO)
Labels: runtime

Version: Deno 1.39.0

This has become a problem because `Writer` is deprecated now. This means that `stdout` and `stderr` can't have a `Writer` interface anymore.

This code will fail with an error on one of the two calls to `getWriter()`. 
```typescript
import { sleep } from "../mod.ts";

await Promise.all([
  (async () => {
    const writer = Deno.stdout.writable.getWriter();
    console.error("got 1");
    try {
      for (let i = 0; i < 10; i += 2) {
        await writer.write(new TextEncoder().encode(`${i}\n`));
        await sleep(1000);
      }
    } finally {
      writer.releaseLock();
    }
  })(),
  (async () => {
    const writer = Deno.stdout.writable.getWriter();
    console.error("got 2");
    try {
      for (let i = 1; i < 10; i += 2) {
        await writer.write(new TextEncoder().encode(`${i}\n`));
        await sleep(1000);
      }
    } finally {
      writer.releaseLock();
    }
  })(),
]);
```

This is a problem if different libraries try to use this to write to stdout asynchronously. 

My understanding of stdout and stderr is that writes to these should pretty much never fail, and should be available to any part of the application. One part of the application should not be able to block access to stdout or stderr in another part, asynchronous or synchronous.

My first thought on this is that this could be solved by removing `writable` from stdout/stderr and making stdout/stderr a full `WritableStreamDefaultWriter`, where they are both currently `Writer` and `WriterSync` now. That would be a pretty bad break of the API though, I realize. No way to make it backward compatible, as some of the method names overlap.

I discovered this problem a while back, but it has become more of a problem now that `Writer` is going away. I was able to legally work around it until now.
Repository: nvm
Issue: [ls-remote] only list active and/or maintained versions
Labels: feature requests

#### What happened?

Currently `nvm ls-remote --lts` literally list all the LTS versions, including the ones are no longer in active and/or maintenance status.


#### What did you expect to happen?

The most common usage of `nvm ls-remote` is to check for new versions, which is only relevant for currently supported versions, namely the ones in active and/or maintenance phases.

Therefore it would make sense to allow one to only list the currently supported versions, or to exclude the no longer supported versions.

If the default behavior cannot be changed, it would make sense to introduce certain command line options, such as `--supported` or `--no-supported`.

And we can use awk to parse the nodejs [release schedule json](https://github.com/nodejs/Release/blob/main/schedule.json) to find supported versions, with `end` date later than the current date, for example:

```sh
$ curl -sL https://raw.githubusercontent.com/nodejs/Release/main/schedule.json |\
  awk -vT=$(date +%F) '{if($1~/v[0-9]+/){v=$1;gsub(/[":]/,"",v);while($1!~/end/)getline;
  e=$2;gsub(/[",]/,"",e);if(e>=T)print v,e}}'
v18 2025-04-30
v20 2026-04-30
v21 2024-06-01
v22 2027-04-30
v23 2025-06-01
v24 2028-04-30
```
Repository: deno
Issue: triple-slash directive fails to type check with `checkJs` enabled
Labels: bug

Version: Deno 1.39.0+d51fda9 (canary, x86_64-unknown-linux-gnu)

## Minimal Reproduction

`add.js`
```js
/// <reference types="./add.d.ts" />
export const add = (a) => a + 1
```

`add.d.ts`
```ts
export declare const add: (a: number) => number
```

`use.ts`
```ts
import { add } from "./add.js"
```

`deno.jsonc`
```json
{
  "compilerOptions": { "checkJs": true }
}
```

## Expected behavior

both CLI and LSP type checks `add.js` and `use.ts` according to <https://docs.deno.com/runtime/manual/advanced/typescript/types#using-the-triple-slash-reference-directive>

## Actual behavior

```sh
$ deno check use.ts     
Check file:///home/scarf/repo/deno/cjk_slug/use.ts
error: TS7006 [ERROR]: Parameter 'a' implicitly has an 'any' type.
export const add = (a) => a + 1
                    ^
    at file:///home/scarf/repo/deno/cjk_slug/add.js:2:21

$ deno check add.js                                                                                                                                                                     Check file:///home/scarf/repo/deno/cjk_slug/add.js
error: TS7006 [ERROR]: Parameter 'a' implicitly has an 'any' type.
export const add = (a) => a + 1
```

both fails to type check.
Repository: godot
Issue: Network.disconnect_peer() will terminate client connectivity before any rpc() calls can happen.
Labels: bug,confirmed,topic:network

### Tested versions

- This is reproducible in v4.2.stable.official [46dc27791]

### System information

Godot v4.2.stable - macOS 14.2.0 - Vulkan (Forward+) - integrated Apple M2 Pro - Apple M2 Pro (10 Threads)

### Issue description

When building a dedicated server (in this case a gateway) you will typically send an RPC call to a client with some response, such as a login response, and then disconnect the client. If you perform this function in Godot, the rpc_id call to the client will never be sent as the network.disconnect_peer() will terminate the client before the rpc call happens

### Steps to reproduce

Create a method where an rpc_id(client_id) is sent to a client followed immediately by a network.disconnect_peer(client_id). The disconnected peer will never receive the rpc call.

@rpc("any_peer", "call_local", "reliable")	
func return_login_response( player_id, result ):
	print("Sending login response to client %d" % player_id )
	rpc_id(player_id, "return_login_response", player_id, result )
	network.disconnect_peer(player_id)

### Minimal reproduction project (MRP)

The reproduction steps are not project dependent (e.g. the bug is visible in a brand new project)

N/A
Repository: deno
Issue: Deno KV watch doesn't work locally from other processes
Labels: ext/kv

Version: Deno 1.39.0

Changes across processes are not observed by `.watch()` when dealing with local stores. To reproduce, open a watch like:

```ts
const kv = await Deno.openKv();

const stream = kv.watch([["a"]]);

for await (const entries of stream) {
  console.log(entries);
}
```

And then in another script sharing the same origin (same path):

```ts
const kv = await Deno.openKv();

await kv.set(["a"], "example");
```

Note that the only the original maybe entry is logged.
Repository: puppeteer
Issue: [Bug]: puppeteer.connect crashes Chromium when using --load-extension with uBlock
Labels: bug,upstream,confirmed

### Minimal, reproducible example

```TypeScript
How I reproduce it:

1. Start Chromium with user-data-dir, and install uBlock (1.54.0_0).
2. Copy directory in `Default/Extensions/...`
3. Start Puppeteer with puppeteer.launch({ ... --load-extension=..., --remote-debugging-port=9000 }), pointing to that directory.
4. Attach with separate script: puppeteer.connect({ browserWSEndpoint:  ... })
This causes Chromium to crash.
```

It doesn't crash when:
- using other extensions, e.g. AdBlockPlus (but is missing a filter that is available in uBlock)
- using a user-data-dir where the extension is preinstalled (and without using --load-extension)


### Error string

crash without error message

### Bug behavior

- [ ] Flaky
- [ ] PDF

### Background

I've tried various launch args, but nothing prevents a crash.


### Expectation

not crashing

### Reality

crashing

### Puppeteer configuration file (if used)

_No response_

### Puppeteer version

21.6.1

### Node version

18.19.0

### Package manager

npm

### Package manager version

10.2.3

### Operating system

Linux
Repository: ant-design
Issue: Fixed column header with rounded corners cannot cover the rows behind while scrolling
Labels: 🐛 Bug,help wanted,Inactive,unconfirmed

### What problem does this feature solve?

https://codesandbox.io/p/sandbox/fixed-columns-antd-5-12-3-rzkvhl

This issue can be reproduced in official demo also. The column 'Action' has rounded corner, while scrolling rows horizontally and the row behind will be exposed through the rounded

before scrolling horizontally:
<img width="785" alt="Screen Shot 2023-12-19 at 16 39 48" src="https://github.com/ant-design/ant-design/assets/40763911/07188c57-7c8e-4ec9-a222-7797b45e2558">

after scrolling, and the rounded corner disappeared
<img width="552" alt="Screen Shot 2023-12-19 at 16 40 29" src="https://github.com/ant-design/ant-design/assets/40763911/71577898-6d33-4608-9455-d8d724bb2d33">


### What does the proposed API look like?

The corners with border radius can fully cover rows under it.

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->