All Issues
24,993 verified issues
Native wayland support with newest electron
Native wayland support would be great to run vs code without XWayland as described in https://github.com/microsoft/vscode/issues/77752. Recently electron merged the chrome version with the ozone backend needed: https://github.com/electron/electron/pull/26022 This would allow for: - Kinetic scrolling (maybe this is more elegantly implemented on the elctron side) - Better touch support (touch scrolling) - better dpi scaling
Git: Support git with private key password
- VSCode Version: 1.6.0 - Commit e52fb0bc87e6f5c8f144e172639891d8d8c9aa55 - Date 2016-10-10T18:37:40.189Z - Shell 1.3.7 - Renderer 52.0.2743.82 - Node 6.5.0 - OS Version: Windows 7 Pro Steps to Reproduce: 1. Create a public-private key pair with password protection 2. add them to your github account 3. setup git to use the private key file 4. try to push something with git Result: [code block]
npm ERR! Unexpected token '.' with with nvm-windows <= 1.1.7
Is there an existing issue for this? - [X] I have searched the existing issues This issue exists in the latest npm version - [X] I am using the latest npm Current Behavior I have updated to the latest npm v8.3.1 and it is showing me an error while using the command "npm outdated -g --depth=0". See the image; https://imgur.com/a/5fMZlye. It was fine on v8.3.0. What is the solution? Expected Behavior It should return the outdated packages after a successful run. But it is giving error. Steps To Reproduce 1. In this environment... 2. With this config... 3. Run '...' 4. See error... I am using Windows 10 (Enterprise - Latest Version). I have the latest node and npm installed at the moment. Environment - npm: - Node.js: - OS Name: - System Model Name: - npm config: [code block] ; "user" config from C:\Users\Bilal\.npmrc registry = "http://registry.npmjs.org/" ; node bin location = C:\Program Files\nodejs\node.exe ; cwd = C:\Users\Bilal ; HOME = C:\Users\Bilal ; Run `npm config ls -l` to show all defaults.
Disable runner auto update
Describe the bug We are running the runner in docker containers and it is forcing us to update the runner and shuts it down. Is there any way we can disable this? https://github.com/ydataai/docker-github-runner -> project with the Dockerfile to build runner in containers To Reproduce 1. Go to the folder where you have github-runner 2. execute ./run.sh 3. Run a job Expected behavior I want to run the runner without it forcing me to update and shutting down my docker Runner Version and Platform Version of your runner? v2.169.1 OS of the machine running the runner? Linux Job Log Output [code block] Runner and Worker's Diagnostic Logs Doesn't seem relevant.
autocomplete for fish shell
I see there is already a virt env for fish (/usr/local/aws/bin/activate.fish) can you please also add an autocompleter for the fish shell?
Be able to update or retrieve a single record including non-unique fields in the "where" conditions.
Problem I am unable to utilize non-unique fields in single update queries. To be clear, I want to still use the unique fields, I just want to filter it down even more. Suggested solution Here are my models [code block] I have "people" who have "clients" attached to them. Only the person who owns the client can update the name. So when an API call comes in, I know who the current person is and what client they're trying to update. So the update query I would like to use is this: [code block] but it only allows fields which are marked as `@unique` or `@id` Alternatives One alternative is to do a `.findUnique({ where: { id: input.clientId } })` and then check if the personId of the client is the same as the one passed in. This however creates two database calls where only one is needed. Another alternative is to do a `.updateMany({ where: { id: input.clientId, personId: input.personId } })` but I don't get any of the clients back. If I got the clients back in the query and if there was a `limit` I could pass in to limit it to one, I would feel better about this so it wouldn't have to do any unneeded scans of the rows, but it still feels less idiomatic than updating the `.update()` command to allow for non-unique fields.
Suggestion: minification
TypeScript should support emitting minified JavaScript. There are several different things we could support: 1. Just remove whitespace 2. Minify unobservable identifiers 3. Remove provably dead code 4. Whole-program minification (i.e. closure compiler) 5. (Others?)
[Android] Error: Duplicate resources
- [x] Review the documentation: https://facebook.github.io/react-native - [x] Search for existing issues: https://github.com/facebook/react-native/issues - [x] Use the latest React Native release: https://github.com/facebook/react-native/releases Environment React Native Environment Info: System: OS: macOS 10.14 CPU: (4) x64 Intel(R) Core(TM) i5-7267U CPU @ 3.10GHz Memory: 103.10 MB / 8.00 GB Shell: 3.2.57 - /bin/bash Binaries: Node: 8.12.0 - /usr/local/bin/node Yarn: 1.0.1 - /usr/local/bin/yarn npm: 6.4.1 - /usr/local/bin/npm Watchman: 4.7.0 - /usr/local/bin/watchman SDKs: iOS SDK: Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1 Android SDK: API Levels: 16, 17, 19, 21, 23, 24, 25, 26, 27, 28 Build Tools: 19.1.0, 20.0.0, 23.0.1, 23.0.2, 23.0.3, 25.0.0, 25.0.1, 25.0.2, 25.0.3, 26.0.0, 26.0.1, 26.0.2, 26.0.3, 27.0.0, 27.0.1, 27.0.3, 28.0.0, 28.0.0, 28.0.2, 28.0.3 System Images: android-16 | ARM EABI v7a, android-16 | MIPS, android-16 | Intel x86 Atom, android-16 | Google APIs Intel x86 Atom, android-19 | Google APIs Intel x86 Atom, android-24 | Google Play Intel x86 Atom, android-26 | Google APIs Intel x86 Atom, android-26 | Google APIs Intel x86 Atom_64, android-26 | Google Play Intel x86 Atom, android-27 | Google Play Intel x86 Atom, android-28 | Google APIs Intel x86 Atom, android-P | Google APIs Intel x86 Atom, android-P | Google Play Intel x86 Atom IDE
Suggestion: `throws` clause and typed catch clause
The typescript type system is helpful in most cases, but it can’t be utilized when handling exceptions. For example: [code block] The problem here is two fold (without looking through the code): 1. When using this function there’s no way to know that it might throw an error 2. It’s not clear what the type(s) of the error is going to be In many scenarios these aren't really a problem, but knowing whether a function/method might throw an exception can be very useful in different scenarios, especially when using different libraries. By introducing (optional) checked exception the type system can be utilized for exception handling. I know that checked exceptions isn't agreed upon (for example Anders Hejlsberg), but by making it optional (and maybe inferred? more later) then it just adds the opportunity to add more information about the code which can help developers, tools and documentation. It will also allow a better usage of meaningful custom errors for large big projects. As all javascript runtime errors are of type Error (or extending types such as `TypeError`) the actual type for a function will always be `type | Error`. The grammar is straightforward, a function definition can end with a throws clause followed by a type: [code block] When catching the exceptions the syntax is the same with the ability to declare the type(s) of the error: `catch(e: string | Error) { ... }` Examples: [code block] Here it’s clear that the function can throw an error and that the e
Concerns with TypeScript 4.5's Node 12+ ESM Support
For TypeScript 4.5, we've added a new module mode called `node12` to better-support running ECMAScript modules in Node.js. Conceptually, the feature is simple - for whatever Node.js does, either match it or overlay something TypeScript-specific that mirrors thes same functionality. This is what TypeScript did for our initial Node.js support (i.e. `--moduleResolution node` and `--module commonjs`); however, the feature is much more expansive, and over the past few weeks, a few of us have grown a bit concerned about the complexity. I recently put together a list of user scenarios and possibly useful scripts for a few people on the team to run through, and we found a few sources of concerns. Bugs UX Ecosystem User Guidance Bugs Most complex software ships with a few bugs. Obviously, we want to avoid them, but the more complex a feature is, the harder it is to cover all the use-cases. As we get closer to our RC date, do we feel confident that what we're shipping has as few blocking bugs as possible? I would like to say we're close, but the truth is I have no idea. It feels like we'll have to keep trying the features for a bit until we don't run into anything - but we have less than 3 weeks before the RC ships. Here's a few surprising bugs that need to get fixed before I would feel comfortable shipping `node12` in stable. Code changes breaking module resolution https://github.com/microsoft/TypeScript/issues/46373 https://github.com/microsoft/TypeScript/issues
Integrate with the Windows 11 Context Menu
The new Windows 11 context menu uses IExplorerCommand + app identity for app integration. Identity is established for unpackaged Win32 like VS Code using Sparse Manifests. A sample can be found here: https://github.com/microsoft/AppModelSamples/tree/master/Samples/SparsePackages The context menu extension is useful for a few key reasons: 1. File Type associations don't work with extensionless files 2. A context menu verb is the only way to open a whole folder of files in VS Code 3. File Type Associations can be an extra set of steps when opening a file is a one-off action
[ANDROID] SoLoader error using App Bundle
🐛 Bug Report Please help! There are some crashes happening in android using app bundle but I am not sure how to reproduce it. It happens on our app with daily crash of 200 users. [code block] The errors have multiple variations that occur on various android versions. [code block] [code block] [code block] To Reproduce We have tried to reproduce it with many devices but we can only reproduce it in one condition. 1. Install the release app 2. Upgrade OS from 32bit to 64bit 3. Open the app If we reinstall the app afterwards, it works fine. Although, we are still unsure whether it is the only error case. Expected Behavior The app does not crash on any device. Code Example [code block] Environment [code block]
Allow custom domains for API & Storage
Feature request Hi! I'd love to be able to set a custom domain alias for my supabase project url, so that instead: the users would see "Chose an account to continue to myproject.mydomain.org". Is your feature request related to a problem? Please describe. The google sign in will show: "Choose an account to continue to dalihgspogdhpodshhofdgogdssg.supabase.co which looks completely like phishing to anyone who received an 101 phishing-defense training. So this is not purely aesthetic problem, but a business one - imagine you prototype a product using Supabase (which it is great at) but you loose conversion because users are afraid to sign in (being worried that some strange jfdsljfdsfuds.supabase.co people will get access to their precious Google account)! :fearful: Describe the solution you'd like Implement a basic custom domain support using LetsEncrypt free/automatic cert generation to secure it. Not hard to implement! This would require: - [ ] setting custom domains in project settings - [ ] supabase proxy generating LetsEncrypt SSL cert to be able to serve the domain securely (alternatively, let user upload a commercial SSL cert) Describe alternatives you've considered I did search GH issues to learn if you have considered custom domains and decided against them for reasons; but I could not find any such discussions. Additional context None, thank you for great work and FLOSS generosity of your enterprise!
RCTBridge required dispatch_sync to load RCTDevLoadingView. This may lead to deadlocks
I randomly get this warning at iOS app start (i.e. not always). Is this a bug report? Yes Have you read the Contributing Guidelines? Yes Environment OS: macOS Sierra 10.12.6 Node: 6.10.2 Yarn: 1.0.2 npm: 5.4.2 Watchman: 4.7.0 Xcode: Xcode 9.0 Build version 9A235 Android Studio: 2.1 AI-143.2915827 Packages: (wanted => installed) react: ^16.0.0 => 16.0.0 react-native: ^0.49.3 => 0.49.3 Steps to Reproduce 1. Start the app Expected Behavior No warning Actual Behavior <img width="432" alt="capture d ecran 2017-10-15 12 49 45" src="https://user-images.githubusercontent.com/160279/31584109-0fc35620-b1a8-11e7-88c2-cbbdd383fc84.png"> Reproducible Demo N/A Some packages I use https://github.com/antoinerousseau/react-native-custom-components https://github.com/rebeccahughes/react-native-device-info https://github.com/evollu/react-native-fcm https://github.com/gwmccull/react-native-polyfill https://github.com/getsentry/react-native-sentry
Firebase Auth is no longer working in incognito mode
[REQUIRED] Describe your environment Operating System version: Windows 10 Browser version: Version 81.0.4044.129 (Official Build) (64-bit) Firebase SDK version: 7.13.1 Firebase Product: auth [REQUIRED] Describe the problem Multiple of our users has reported, they are no longer able to login and use our product... After some investigation, it seems to happen for all the users, which accesses our platform in incognito mode. It seems to no longer be possible to use the firebase auth SDK in Google Incognito mode. The exact same users can log in with the exact same credentials or SSO integrations through firebase in non-incognito. Steps to reproduce: If users try to use firebase authentication on our platform in incognito mode, the error: `{code: "auth/web-storage-unsupported", message: "This browser is not supported or 3rd party cookies and data may be disabled.", a: null}` is thrown from the SDK. I believe it potentially can be an issue in a newer Chrome update, as I know Google has been experimenting with having Chrome block 3rd Party Cookies (I believe they experimented with it in version 83 of Chrome, which I am not using though).
couldn't find DSO to load: libjscexecutor.so caused by: dlopen failed: library "libjsc.so" not found
App crash on Android integration with existing apps. Crash log. [code block] React Native version: System: OS: macOS 10.14.5 CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz Memory: 1.19 GB / 16.00 GB Shell: 5.3 - /bin/zsh Binaries: Node: 12.5.0 - /usr/local/bin/node Yarn: 1.16.0 - /usr/local/bin/yarn npm: 6.9.0 - /usr/local/bin/npm Watchman: 4.9.0 - /usr/local/bin/watchman SDKs: Android SDK: API Levels: 21, 22, 23, 24, 25, 26, 27, 28, 29 Build Tools: 23.0.1, 25.0.2, 26.0.2, 27.0.3, 28.0.0, 28.0.3, 29.0.0, 29.0.0 System Images: android-22 | Google APIs Intel x86 Atom, android-23 | Google APIs Intel x86 Atom, android-25 | Google APIs Intel x86 Atom, android-27 | Google Play Intel x86 Atom, android-28 | Google APIs Intel x86 Atom, android-29 | Google Play Intel x86 Atom IDEs: Android Studio: 3.4 AI-183.6156.11.34.5522156 Xcode: /undefined - /usr/bin/xcodebuild npmPackages: react: 16.8.6 => 16.8.6 react-native: ^0.60.0 => 0.60.0 npmGlobalPackages: react-native-cli: 2.0.1 Steps To Reproduce 1. Create a new Android app which uses AndroidX. 2. Add react-native to Android application as, implementation 'com.facebook.react:react-native:+' 3. Run app on any android device/emulator. Sample project on GitHub which reproduces crash.
HMR breaks when modifying React context provider
Describe the bug Vite HMR breaks when modifying React context provider Related: https://github.com/vitejs/vite-plugin-react/issues/24 Reproduction selrond/vite-react-usecontext System Info Output of `npx envinfo --system --npmPackages vite,@vitejs/plugin-vue --binaries --browsers`: [code block] Used package manager: npm Logs --- Before submitting the issue, please make sure you do the following - [x] Read the Contributing Guidelines. - [x] Read the docs. - [x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate. - [x] Provide a description in this issue that describes the bug. - [x] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead. - [x] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
Job-level "if" condition not evaluated correctly if job in "needs" property is skipped
Describe the bug If a job `needs` a prior job which has been skipped, the `if` condition for the dependent job may behave unexpectedly under some conditions. (unsure if condition is evaluated incorrectly or if it's not evaluated at all) To Reproduce Steps to reproduce the behavior: Given a workflow such as this (where job_b needs to complete or be skipped before subsequent jobs run, but subsequent jobs don't depend upon any outputs from job_b) [code block] Examining the output of this workflow, job_a will always run, job_b will always be skipped, job_c will always be skipped, and job_d will run. The only difference between job_c and job_d is the addition of `always() &&` to the `if` condition. Expected behavior If a job-level conditional evaluates to `true`, the job should run after all `needs`'d jobs have completed or been skipped. _Both_ job_c and job_d should run. The `always() &&` should not be required for job_c, since it doesn't change the ultimate true/false result of the conditional. OR documentation should be updated to indicate this is expected behavior. The current docks simply says of job `needs` (emphasis added): > Identifies any jobs that must complete successfully before this job will run. It can be a string or array of strings. If a job fails, all jobs that need it are skipped unless the jobs use a conditional statement that causes the job to continue. This is relatively ambiguous, but the plain interpretation is that a conditional statement that evaluates
TypeError: axios.get is not a function (v1.1.0)
Describe the bug The new version of axios (v1.1.0) is throwing an error for `axios.get`: `TypeError: axios.get is not a function`. Note: This issue was not present in v1.0.0 To Reproduce Include axio v1.1.0 via a `<script>` tag, and then reference it directly via `axios.get()` [code block] Expected behavior `axios.get` should be a valid function. Environment - Axios Version 1.1.0
Segmentation fault crash when using prisma client when using PostgreSQL
Bug description When trying to use `findMany()` (or any other method) on a model, prisma client crashes and the following line appears in my log: `Segmentation fault (core dumped)`. This only happens if I use PostgreSQL as far as I know, this first appeared when I switched to PostgreSQL from mysql. How to reproduce 1. Initiate a new prisma project (make sure to use PostgreSQL) and generate the client - no errors there 2. Write a simple client which fetches some data from the databse 3. The script crashes and `Segmentation fault (core dumped)` gets logged in the console Expected behavior The script does not crash. Prisma information Example schema: [code block] Example test client: [code block] Environment & setup - OS: Pop!_OS (`Linux pop-os 5.15.5-76051505-generic #202111250933~1638201579~21.04~09f1aa7-Ubuntu SMP Tue Nov 30 02: x86_64 x86_64 x86_64 GNU/Linux`) - Database: PostgreSQL v14.1 (Ubuntu 14.1-1.pgdg21.04+1) - Node.js version: v17.2.0 Prisma Version [code block]