sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: material-ui
Issue: The type of styled-component does not match for "strict: true"
Labels: typescript

When we use styled-component in TypeScript to inherit the Material-UI component, props type does not match.
How do I overwrite a style with styled-component?

There is a sample on how to inherit in the case of styled-component in the following link, but this sample will generate an error if it is set to `strict: true` in tsconfig setting.

https://material-ui.com/guides/interoperability/#styled-components

```jsx
import React from 'react';
import styled from 'styled-components';
import Button from '@material-ui/core/Button';

const StyledButton = styled(Button)`
  background: linear-gradient(45deg, #fe6b8b 30%, #ff8e53 90%);
  border-radius: 3px;
  border: 0;
  color: white;
  height: 48px;
  padding: 0 30px;
  box-shadow: 0 3px 5px 2px rgba(255, 105, 135, .3);
`;

function StyledComponentsButton() {
  return (
    <div>
      <Button>
        Material-UI
      </Button>
      <StyledButton>
        Styled Components
      </StyledButton>
    </div>
  );
}

export default StyledComponentsButton;
```

The way I tried is to cast the component with React.SFC and then pass the props type of the material-ui component to that generics.

```jsx
import TextField, { TextFieldProps } from "@material-ui/core/TextField";

export const StyledTextField = styled(TextField as React.SFC<TextFieldProps>)`
  // some style
`;
```

in this case

```
Type '{ disabled: true; label: string; defaultValue: string; variant: "outlined"; }' is missing the following properties from type 'Pick<Pick<TextFieldProps.....
```

The above error will be displayed :(

It was able to solve by the following method.

```jsx
interface TextFieldProps {
  disabled: boolean;
  label: string;
  defaultValue: string;
  variant: string;
}

export const StyledTextField = styled(TextField as React.SFC<TextFieldProps>)`
  // some style
`;
```

However, I do not think this is a nice implementation. Required Props
It is because you have to re-implement the interface every time it changes.

---

@material-ui/core version: 3.6.2
@material-ui/icons version: 3.0.1
styled-components version: 4.1.2
typescript version: 3.2.2

macOS: 10.13.6
Repository: TypeScript
Issue: Allow local .js/.ts files to be typed by their corresponding .d.ts file
Labels: Suggestion,Awaiting More Feedback

## Suggestion

If I have `source/index.js` which has:

``` javascript
function isObject(value) {
	// null is object, hence the extra check
	return value !== null && typeof value === 'object'
}
```

And then I supply a `source/index.d.ts` file which has:

``` javascript
/** Checks to see if a value is an object */
export function isObject(value: any): boolean
```

And I update `package.json:types` to `source/index.d.ts`.

Then I should not receive the following error in `source/index.js`:

```
[ts] Parameter 'value' implicitly has an 'any' type. [7006]
(parameter) value: any
```

And I should get complete intellisense.

## Use Cases

This approach has the following benefits:

1. Source files can run without compilation, this has been incredibly useful for @bevry's hundreds of packages, which are all written in jsdoc'd esnext that runs on mostly node 4 and above, with compilation only for older node versions (but most of the time, it is our source code that is running, thanks to [editions](https://editions.bevry.me))
2. JSDoc types do not provide intellisense nor type checking for typescript consumers
3. TypeDoc for documentation seems nicer than JSDoc, especially with overloads
4. Going all in on TypeScript may be too much to ask for, for many module authors - as a typescript project requires types for all its dependencies, as well as accurate (rather than merely simplistic) mappings, which some of the time, is just too inconvenient to bother with - [such as this](https://stackoverflow.com/q/53612877/130638), as well as [eachr](https://github.com/bevry/eachr/tree/dev-typescript-dts) which a pure typescript conversion seems impossible to me (after days of effort, as typescript always whines about incorrect types)

Alternatives to this would be:

1. Have typescript projects support intellisense and type checking for jsdoc js files
2. Automatically generate .d.ts files for jsdoc js files

For now, the best workaround seems to be:

1. Spend weeks upon weeks converting your hundreds of modules to typescript to satisfy typescript's need for types for everything
2. Provide jsdoc .js files, and manual .d.ts files

## Examples

- https://github.com/bevry/typechecker/tree/dev-typescript-dts
- https://github.com/bevry/eachr/tree/dev-typescript-dts

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [ ] This wouldn't change the runtime behavior of existing JavaScript code
* [ ] This could be implemented without emitting different JS based on the types of the expressions
* [ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [ ] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

I haven't filled out this checklist as I do not know enough about typescript's inner workings to be able to fill it out.
Repository: create-react-app
Issue: Put TypeScript configuration in react-scripts instead of individual project? (TS3.2+)
Labels: issue: proposal

### Is this a bug report?

No

### Motivation

[TypeScript 3.2](https://blogs.msdn.microsoft.com/typescript/2018/11/29/announcing-typescript-3-2/#configuration-inheritance-via-node_modules-packages), released November 29th, 2018, now uses [Node.js-based resolution for tsconfig.json inheritance](https://blogs.msdn.microsoft.com/typescript/2018/11/29/announcing-typescript-3-2/#configuration-inheritance-via-node_modules-packages)

> TypeScript 3.2 now resolves `tsconfig.jsons` from `node_modules`. When using a bare path for the `"extends"` field in `tsconfig.json`, TypeScript will dive into `node_modules` packages for us.
>
> ```js
> {
>     "extends": "@my-team/tsconfig-base",
>     "include": ["./**/*"]
>     "compilerOptions": {
>         // Override certain options on a project-by-project basis.
>         "strictBindCallApply": false,
>     }
> }
> ```

TypeScript will look for `"tsconfig"` field in `package.json` to determine the configuration file to use.

Therefore, the generated `tsconfig.json` could be reduced to

```js
{ "extends": "react-scripts", "include": ["src"] }
```

This would further reduce configuration in create-react-app projects.
Repository: flutter
Issue: FEATURE REQUEST: NetworkImage should accept different protocols
Labels: c: new feature,framework,P3,team-framework,triaged-framework

NetworkImage uses HTTP and accepts a **url String**, what if I want to use another protocol like gRPC?
Should I rewrite the class? (BAD)
Repository: TypeScript
Issue: Improve structure, formatting, (human) parsability and readabiliy of errors
Labels: Suggestion,Committed,Domain: Error Messages

## Suggestion

Comparing my DX/UX experience from working with flow versus TypeScript, the error messages is one of the few things that I preferred how flow does it. Especially after flow v0.66 release. I believe they integrated alot from the [glow](https://github.com/jamiebuilds/glow) project. I would love it if typescript would adopt some for the formatting and helpful information that flow has in their error messages.

This blog post explains more about the flow 0.66 error message changes: http://medium.com/flow-type/better-flow-error-messages-for-the-javascript-ecosystem-73b6da948ae2

Here are a couple of things I can think of that would help me find the actual problem/conflict that I can take action on:

- prettifying/formatting the outputted types
- syntax highlighting
- bold/highlight the conflicting parts

## Use Cases

Every time typescript finds an error (which us developers will have to read and understand and take action on :) ). I am talking both on the command line but also in IDEs like vscode. There is an issue related to this in the vscode repo here: https://github.com/Microsoft/vscode/issues/54503

## Examples

Heres and example of the ginormous unstructured blob of text that is a ts error with big types involved:

```Type '({ expandedRowIds, orderBy, currentPage, filters: { columns: columnFilters, period, categoryIds }, ...restUrlQueryState }: Pick<Overwrite<DataGridUrlQueryStateUrlSerialized, { filters: { columns: { promotionName?: string | undefined; startDate?: string | undefined; endDate?: string | undefined; "sumFacts.switching.amount"?: string | undefined; "sumFacts.netLift.profit"?: string | undefined; "sumFacts.netLift.amount"?: string | undefined; }; period: Date[]; categoryIds: string[]; }; }>, "hiddenColumnNames" | "filters" | "orderBy" | "expandedRowIds" | "currentPage">, pageSize: any) => Dictionary<any>' is not assignable to type '(a: Overwrite<DataGridUrlQueryStateUrlSerialized, { filters: { columns: { promotionName?: string | undefined; startDate?: string | undefined; endDate?: string | undefined; "sumFacts.switching.amount"?: string | undefined; "sumFacts.netLift.profit"?: string | undefined; "sumFacts.netLift.amount"?: string | undefined; }; period: Date[]; categoryIds: string[]; }; }>) => DataGridQueryVariables'.```

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [ ] This wouldn't change the runtime behavior of existing JavaScript code
* [ ] This could be implemented without emitting different JS based on the types of the expressions
* [ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [ ] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: Momentum problem (1-momentum is correct?) in BatchNorm2d
Labels: todo,module: docs,module: nn,triaged

## 🐛 Bug

In BatchNorm2d' doc, the explanation of momentum is:
`\hat{x}_\text{new} = (1 - \text{momentum}) \times \hat{x} + \text{momemtum} \times x_t$`

where `x_t` is the newly computed batch statistics, `\hat{x}` is the estimated statistics in history.
While in my experiments, when momentum set to 0, the batchnorm operates just use the newly computed statistics.

So I guess maybe the following explanation is correct:

`\hat{x}_\text{new} = \text{momemtum\times \hat{x} + (1 - \text{momentum}) \times x_t$`

## To Reproduce

`b_x` is a torch.Tensor with shape (8, 3, 299, 299), which read from an image
`mol` is the model load from `Inception V3`
I have set the momentum as 0 in [Inception v3 model struct](https://github.com/pytorch/vision/blob/master/torchvision/models/inception.py):

```python
class BasicConv2d(nn.Module):

    def __init__(self, in_channels, out_channels, **kwargs):
        super(BasicConv2d, self).__init__()
        self.conv = nn.Conv2d(in_channels, out_channels, bias=False, **kwargs)
        self.bn = nn.BatchNorm2d(out_channels, eps=0.001, momentum=0)

    def forward(self, x):
        x = self.conv(x)
        x = self.bn(x)
        return F.relu(x, inplace=True)
```

Then I calculate the mean and var:
``` python
conv = mol.Conv2d_1a_3x3.conv(b_x)
dim = conv.shape
m = (conv.sum(0).sum(1).sum(1)/(dim[0]*dim[2]*dim[3])).view(1, -1, 1, 1)
var = (((conv-m)**2).sum(0).sum(1).sum(1)/(dim[0]*dim[2]*dim[3]-1)).view(1, -1, 1, 1) + 0.001
tmp = (conv - m) / torch.sqrt(var)
tmp = tmp * mol.Conv2d_1a_3x3.bn.weight.view(1, -1, 1, 1) + mol.Conv2d_1a_3x3.bn.bias.view(1, -1, 1, 1)
bn = mol.Conv2d_1a_3x3.bn(conv)
print((bn-tmp).mean(), (bn-tmp).std())
```

The result is that `bn=tmp` while `momentum = 0`

## Expected behavior

Expected `bn=tmp` while `momentum = 1`

## Environment

 - PyTorch Version 0.4.1:
 - Windows:
 - pip:
 - Python version: 3.6.5


cc @brianjo @mruberry @albanD @jbschlosser
Repository: opencv
Issue: Add support for cv.imwrite for opencvJS. 
Labels: category: javascript (js)

opencvJS running on a browser does not have support for [imwrite](https://docs.opencv.org/master/d4/da8/group__imgcodecs.html#gabbc7ef1aa2edfaa87772f1202d67e0ce). We should consider implementing using the upcoming [W3C writable files](https://github.com/WICG/writable-files), when the proposal matures and there is support from browser vendors.

32-bit float (CV_32F) images can be saved in PFM, TIFF, OpenEXR, and Radiance HDR formats. These HDR/high quality images cannot be displayed on the screen using cv.imshow(canvas, mat) because of [canvas's limitation of using only  cv.CV_8UC4](https://docs.opencv.org/master/df/d24/tutorial_js_image_display.html). So it is important to save the images and then display using `<img>` element.
Repository: TypeScript
Issue: Adding generic parameter to a lambda function removes typing from the function argument
Labels: Bug,Domain: Contextual Types

**TypeScript Version:**  3.2.2

**Search Terms:** generic removes parameter type

**Code**

```ts
// OKAY
// declare const labmda function with typings, then implement with minimal type annotations.
// "input" has type of "string".
export const foo: (input: string) => string
    = (input) => (input);

// OKAY
// declare const lambda generic function without typings, then implement with full inline type annotations.
// "input" has type of "string".
export const bar
    = <TResult>(input: string) => ({ } as Partial<TResult>);

// ERROR
// declare const labmda generic function with typings, then implement with minimal type annotations.
// "input" has type of "any".
export const baz: <TResult>(input: string) => Partial<TResult>
    = <TResult>(input) => ({ [input]: input } as Partial<TResult>);
```

**Expected behavior:**
`input` is typed as `string`.

**Actual behavior:**
`input` is typed as `any`.

**Playground Link:** https://www.typescriptlang.org/play/index.html#src=%2F%2F%20OKAY%0D%0A%2F%2F%20declare%20const%20labmda%20function%20with%20typings%2C%20then%20implement%20with%20minimal%20type%20annotations.%0D%0A%2F%2F%20%22input%22%20has%20type%20of%20%22string%22.%0D%0Aexport%20const%20foo%3A%20(input%3A%20string)%20%3D%3E%20string%0D%0A%20%20%20%20%3D%20(input)%20%3D%3E%20(input)%3B%0D%0A%0D%0A%2F%2F%20OKAY%0D%0A%2F%2F%20declare%20const%20lambda%20generic%20function%20without%20typings%2C%20then%20implement%20with%20full%20inline%20type%20annotations.%0D%0A%2F%2F%20%22input%22%20has%20type%20of%20%22string%22.%0D%0Aexport%20const%20bar%0D%0A%20%20%20%20%3D%20%3CTResult%3E(input%3A%20string)%20%3D%3E%20(%7B%20%7D%20as%20Partial%3CTResult%3E)%3B%0D%0A%0D%0A%2F%2F%20ERROR%0D%0A%2F%2F%20declare%20const%20labmda%20generic%20function%20with%20typings%2C%20then%20implement%20with%20minimal%20type%20annotations.%0D%0A%2F%2F%20%22input%22%20has%20type%20of%20%22any%22.%0D%0Aexport%20const%20baz%3A%20%3CTResult%3E(input%3A%20string)%20%3D%3E%20Partial%3CTResult%3E%0D%0A%20%20%20%20%3D%20%3CTResult%3E(input)%20%3D%3E%20(%7B%20%5Binput%5D%3A%20input%20%7D%20as%20Partial%3CTResult%3E)%3B

_(NOTE: options -> `noImplicitAny` to have the issue highlighted as an error.)_

**Related Issues:**

https://github.com/Microsoft/TypeScript/issues/18606
I think this issue might be related, but I don't understand it enough to judge.
If this is the same issue then the answer is "this is correct, and a limitation of the type system", which is fair enough.
Repository: vue-element-admin
Issue: Can git-flow be implemented?
Labels: enhancement :star:

It would be good to implement the git-flow to develop in a more organized and standardized way, you could say that it is the standard way of working in the git world.
Repository: kubernetes
Issue: Lock down allowed upgrade protocols in apiserver proxy to spdy and websockets
Labels: priority/important-soon,area/security,kind/cleanup,area/apiserver,sig/api-machinery,lifecycle/frozen

From [CVE-2018-1002105](https://github.com/kubernetes/kubernetes/issues/71411) [post-mortem](https://docs.google.com/document/d/1tGpqEM56cSBPfl-qxIs_CGdlABMZXEKEDhCI7eOwGT0/edit#)

/assign
/area security
/area apiserver
/priority important-longterm
/kind cleanup
/sig api-machinery
Repository: kubernetes
Issue: Aggregator: prevent upgrade on known paths that do not serve upgrade requests (like discovery, healthz, etc)
Labels: area/security,kind/cleanup,area/apiserver,sig/api-machinery,priority/important-longterm,lifecycle/frozen

From [CVE-2018-1002105](https://github.com/kubernetes/kubernetes/issues/71411) [post-mortem](https://docs.google.com/document/d/1tGpqEM56cSBPfl-qxIs_CGdlABMZXEKEDhCI7eOwGT0/edit#)

/area security
/area apiserver
/priority important-longterm
/kind cleanup
/sig api-machinery
Repository: kubernetes
Issue: Investigate adding per-request binding or assertions to apiserver proxy
Labels: area/security,area/apiserver,sig/api-machinery,kind/feature,priority/important-longterm,lifecycle/frozen

Investigate adding per-request binding or assertions that would let backends verify a particular request was intentionally forwarded from the apiserver proxy

From [CVE-2018-1002105](https://github.com/kubernetes/kubernetes/issues/71411) [post-mortem](https://docs.google.com/document/d/1tGpqEM56cSBPfl-qxIs_CGdlABMZXEKEDhCI7eOwGT0/edit#)

/area security
/area apiserver
/priority important-longterm
/kind cleanup
/sig api-machinery
Repository: TypeScript
Issue: Distinguish between plain object types and class types
Labels: Suggestion,Needs Proposal

## Search Terms

- plain object class type

## Suggestion

Some way to distinguish an object type that only has `Object` in its prototype chain.

## Use Cases

In [this library](https://github.com/mweststrate/immer), we use mapped types to convert immutable objects/arrays into their mutable representation. We _never_ do this for class instances, so I need a way to skip the mapped type when an object type is actually a class type (in order to preserve readonly properties on class instances).

## Examples

I have no suggestions for such syntax.

## Checklist

My suggestion meets these guidelines:

* [ ] 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).

## Related

https://stackoverflow.com/questions/53819550/distinguish-between-plain-objects-and-class-types#53819550
Repository: vue
Issue: Impossible to preserve directive dom changes when the dom element is shared by multiple vnodes.
Labels: improvement

### Version
2.5.17

### Reproduction link
[https://codesandbox.io/s/8y0yqono38](https://codesandbox.io/s/8y0yqono38)







### Steps to reproduce
Create a wrapper component that has another custom component as its root node. Put a directive on the wrapper component that adds a class to the element. Do anything that updates the child's class. The classes assigned in the directive of the parent vnode will be wiped out, and the directive has no way of knowing it. I _think_ this is because the vnodes were merged into the same element. So, the child vnode gets patched, causing the class update and the dom change to the same element that the parent vnode is using, but, because no actual patch happened to the parent vnode, the parent directive never has a chance to readd it's class.

I think this probably _technically_ correct behavior, but it still presents (in my opinion) an issue with directive functionality. Which is that my host dom element can be mutated by a different vnode and I'm not aware of it.

### What is expected?
The `update` trigger runs when my host element is mutated.

### What is actually happening?
The class the directive adds is overwritten and my directive has no chance to readd the class.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: go
Issue: strconv: ParseBool errors are verbose
Labels: NeedsDecision

Failure to parse a boolean flag results in this error:

https://play.golang.org/p/cBBLtiFyWhY:   
```invalid boolean value "garbage" for -b: strconv.ParseBool: parsing "garbage": invalid syntax```

Room for improvement:
- display the offending value only once
- don't mention strconv.ParseBool, as it is an internal detail.
- state what values are allowed, perhaps?

The other strconv.Parse* functions are similarly verbose. I've gotten into the habit of throwing away their errors and writing my own. e.g. "invalid int: %q".
Repository: rust
Issue: Tracking issue: --persist-doctests flag for rustdoc
Labels: T-rustdoc,B-unstable,C-tracking-issue,A-doctests

First implemented in https://github.com/rust-lang/rust/pull/56189, this flag allows users to save the compiled binaries created when rustdoc runs documentation tests.

Pending work:

- [x] Land https://github.com/rust-lang/rust/pull/56189
- [ ] Change the folder naming scheme? i.e. https://github.com/rust-lang/rust/pull/56189#issuecomment-445865048
- [ ] Related option to also save the processed code, for debugging purposes?
- [ ] Ability to cross-compile doctests and either save the binaries or run them through some test runner
- [ ] Combining the binaries into a singular test runner, like how libtest saves a single binary that runs unit tests
Repository: godot
Issue: get_tree().root can't be edited
Labels: bug,topic:gdscript,confirmed

**Godot version:** cf07169 

**OS/device including version:** Ubuntu/Any

**Issue description:**
Trying to change properties of the scene's root with `get_tree().root` will result in a crash. Following error is outputted: "Invalid set index 'root' (on base: 'SceneTree') with value of type 'Viewport'." 
Editing the root is still possible when referring to it with `$"/root/"` instead.

In my opinion both ways of writing should be interchangeable.
Repository: pytorch
Issue: libtorch without cmake 
Labels: module: build,module: cpp,triaged

## 🐛 Bug

I have run the example-app (https://pytorch.org/cppdocs/installing.html) using libtorch and cmake. Now I am going to run it only using an IDE such as Eclipse. I have tried it; however,  using <torch/torch.h> there’s a whole bunch of include files that g++ can’t find. So could you please itemize the necessary steps to run libtorch not using cmake? (As it is mentioned in the above link "CMake is not a hard requirement for using LibTorch")