All Issues
24,993 verified issues
Add login / authentication example
With: - re-usable authentication helper across pages - session synchronization among tabs - simple passwordless email backend hosted on `now.sh` I think this will be hugely helpful to a lot of newcomers.
Proposal: make project-name persistent.
By default, Compose bases the project name on basename of the directory compose commands are run from. The project name can be overridden either by passing a `-p / --project-name` option for each command or setting the `COMPOSE_PROJECT_NAME` environment variable. Using the `--project-name` option for _each_ command is error-prone and for- getting to pass the option when doing (for example) `docker-compose up`, will result in _another_ instance of the project being created under a different name or even containers of a different project being replaced. Using the `COMPOSE_PROJECT_NAME` environment variable is not useful when dealing with multiple projects and can cause similar problems. Proposal: make project-name persistent To solve these problems, compose will save the name of a project to a file in the build-context when the project is first started / built. If a project-file is found, compose automatically uses the project-name from that file and throw an exception if the user is trying to override the project-name using the `--project-name` option. File location To allow further expansion of options, compose creates a hidden `.docker-compose` directory in the "root" directory of the build-context. Inside that directory, a `project-name` file is created, containing just the name of the project; [code block] Request for comment There are a couple of things left to be discussed; - Should the configuration-file be created _automatically_ or should this be an exp
Make Vite work with Vue 2
> Do NOT ignore this template or your issue will have a very high chance to be closed without comment. Describe the bug Trying Vite on a fresh vue 2.5 / typescript app. Reproduction - Create a new app: `npm init vite-app vue25 --template vue` - Replace `package.json` with this: [code block] System Info - required `vite` version: 0.18.0 - required Operating System: macOS Catalina 10.15.4 - required Node version: 10.16.0 - Optional: - npm/yarn version: 6.14.4 - Installed `vue` version (from `yarn.lock` or `package-lock.json`) - Installed `@vue/compiler-sfc` version I thought this worked with Vue 2.5 as @vue/compiler-sfc is vue 3... only.
I see the project was updated a few hours ago, does this support "gpt-3.5-turbo"
Describe the feature or improvement you're requesting I tried the new "gpt-3.5-turbo" with my previous install and I get an 404 error on return. Has this been updated for the new "gpt-3.5-turbo" model? Additional context _No response_
Next.js dev server gets stuck after a while, requests just spin
Bug report Describe the bug When I run my Next.js app with `now dev`, after a while (on the order of minutes, definitely less than an hour) my requests to it will stop working. To Reproduce I'm not sure how to isolate this one. It happens all the time with this project https://github.com/mjm/courier-js but it's not an easy thing to get running for reproduction. 1. Run `now dev` 2. Work on the app, making changes to files, saving, and watching them hot reload in the browser 3. Eventually, one of these changes will try to reload and will get stuck. The on-page indicator for a page compiling will be there and keep spinning continuously. Trying to refresh the page just causes the browser to try to load the page until it times out. When I give up, I can hit Ctrl-C to try to kill the server, but if it's in this state, it can take a minute or two to actually get the message and quit. Expected behavior Continuing to make changes should keep working and trigger refreshes in the browser. System information - OS: macOS Catalina, though I think this happened before upgrading too - Browser (if applies): I've seen in both Chrome and Safari - Version of Next.js: 9.1.7, has happened in earlier versions of Next 9 as well - Version of Now CLI: 16.7.3 Additional context I feel like this could be TypeScript related, but I don't have any evidence. I'm on the latest release for that as well. I'm happy to try things that might help understand what's going on. The only thing I've seen in
Prefer escaping single quotes in strings rather than mixing quote styles.
Currently, this string (`'\'editing\' flag'`) is automatically converted to `"'editing' flag"` - is there a way to prefer escaped single quotes? The value of this preference is that it promotes a consistent code style. In my opinion, there should be an option to leave the single quotes alone. What do you guys think? Edit: I've encountered this issue in my Jest tests and I have the --single-quote option set.
support Microsoft Azure OpenAI service endpoints
Describe the feature or improvement you're requesting Update the API configuration to support Azure openai endpoints as well. In order to use the Python OpenAI library with Microsoft Azure endpoints, we need to set the api_type, api_base and api_version in addition to the api_key. The api_type must be set to 'azure' and the others correspond to the properties of your endpoint. In addition, the deployment name must be passed as the engine parameter. python ========== import openai openai.api_type = "azure" openai.api_key = "..." openai.api_base = "https://example-endpoint.openai.azure.com" openai.api_version = "2022-12-01" create a completion completion = openai.Completion.create(engine="deployment-name", prompt="Hello world") print the completion print(completion.choices[0].text) Additional context _No response_
[BUG] npm audit fix doesn't work
Is there an existing issue for this? - [X] I have searched the existing issues Current Behavior In my project, when running `npm audit`, one of the reported vulnerable packages is listed with the message “fix available via `npm audit fix`”, but running `npm audit fix` doesn’t lead to any updated packages and the exact same output as from the earlier run of `npm audit` is logged. This occurs on https://github.com/kleinfreund/vue-accessible-color-picker/commit/35bec0e751abad872de79657053cb8de07321faa. Which dependency from my package.json file is actually the vulnerable one I cannot tell with the new output of `npm audit` in npm 7. This is what the output looks like: [code block] Expected Behavior When seeing a message with the clear instruction “fix available via `npm audit fix`”, I expect this to be truthful and `npm audit fix` to always produce a changed package-lock.json file. Steps To Reproduce 1. Run `git clone https://github.com/kleinfreund/vue-accessible-color-picker.git` 2. Run `git checkout 35bec0e751abad872de79657053cb8de07321faa` to checkout the commit on the project’s `main` branch at the time of writing this. 3. Run `npm install` 4. Run `npm audit`. ~Observe how currently this includes an entry with the message “fix available via `npm audit fix`”.~ For this particular advisory, this is no longer the case, unfortunately. 5. Run `npm audit fix` Environment - OS: Ubuntu 20.04 - Node: v14.17.1 - npm: 7.19.0
Slow compile when using @apply
I've been experiencing slow compile times when using the @apply rule in my CSS. Here's an example: `.HomePage main .plan h3 { @apply .content-none .absolute .block .border-solid }` Despite having a powerful machine, as the CSS grows, the compile time goes up. It's now gotten to a point where even when running a watcher on save it is over 1.5s. Enough to slow down my workflow. I'm only looking at 100+ lines of CSS (for components). Are there any reasons why it might be slow? Thanks! EDIT: I've determined that it is being caused by the size of the tailwind config JS file. The resulting CSS file being generated is ~500 KB. I've stripped out some colours, but I've added items too e.g. margins and padding. If I have to remove them to get a usable compile time, doesn't that kinda defeat the point of the framework? I want to have many utilities available to me. I think the solution is too structure the build process so that the tailwind config isn't recompiled every time. However, I wonder if this presents a problem with using @apply?
[BUG]: Warning: async_hooks.createHook is not implemented in Bun. Hooks can still be created but will never be called.
What version of `drizzle-orm` are you using? 0.30.9 What version of `drizzle-kit` are you using? 0.20.17 Describe the Bug Bun doesn't support a feature drizzle-kit uses, but bun is an option in your documentation. => db pulling doesn't work using bun, meaning you have to use npm to excecute the drizzle-kit commands which leads to increased complexity, if you want to use drizzle-kit in github actions for example. (Because you need to convert the bun lockfile to a yarn lockfile meaning you have to setup yarn and then npm to execute the scripts in the package.json file). Expected behavior Bun supporting a feature you use in your code if you say it works with bun. Environment & setup npm v18 bun v1.1.6
RCTImageLoader crashes when canceling image loads (RN 0.36)
Image Loader Crashing at OSAtomicOr32Barrier (EXC_BAD_ACCESS) Start of Stack is [code block] Steps to Reproduce / Code Snippets Put some Network Images on the Page (Specially in a List View) then scroll or change tabs so Images which are not loaded yet are out of the View Port and go back to same tab/viewport and you will see this error. Expected Results No Error Additional Information - React Native version: Latest 0.36.rc.0 - Platform(s) (iOS, Android, or both?): iOS - Operating System (macOS, Linux, or Windows?): macOS
Linebreaks weirdly in long ES6 template strings with expressions
Prettier 1.8.2 Playground link [code block] Input: [code block] Output: [code block] Expected behavior: I would prefer a long string to _not_ get split into multiple lines, even if it contains expressions. When there are no expressions, Prettier correctly lets a long string go beyond the `print-width` limit. I can't decide if this is a bug or a personal preference, but it's been creating weird hard to read code in our codebase. We can clean most of it up by simplifying our expressions, but there's only so short we can go.
Suggestion: Add the nameof compile-time operator to convert property and function names into strings
I would like to see the `nameof` operator be considered for Typescript. This feature was just added to Cdescription, and it is an elegant solution to a common issue in Javascript. At compile time, `nameof` converts its parameter (if valid), into a string. It makes it much easier to reason about "magic strings" that need to match variable or property names across refactors, prevent spelling mistakes, and other type-safe features. To quote from the linked Carticle: > Using ordinary string literals for this purpose is simple, but error prone. You may spell it wrong, or a refactoring may leave it stale. nameof expressions are essentially a fancy kind of string literal where the compiler checks that you have something of the given name, and Visual Studio knows what it refers to, so navigation and refactoring will work: `(if x == null) throw new ArgumentNullException(nameof(x));` To show another example, imagine you have this Person class: [code block] If I have an API that requires me to specify a property name by string (pretty common in JS), I am forced to do something like this: [code block] But if I misspell `firstName`, I'll get a runtime error. So this is the type-safe equivalent: [code block]
Publish packages for each individual API.
This is going to be done in several steps: - [x] Re-organize the directory structure to map to individual modules (#1167) - [x] Setup and publish a `googleapis-common` npm module that just contains shared bits that will be used by all packages - [x] Generate a package.json for all of the individual APIs - [ ] Script the `npm publish` process so that each individual package is published along with the larger meta-package These steps are of course subject to change as we discover things through the process :) --- UPDATE --- We're down to the last step of actually publishing the individual modules. @alexander-fenster, @jkwlui, and @JustinBeckwith last got together to chat about this, and came to a few conclusions: State of the world today - We decide when to run the generator in a somewhat ad-hoc fashion. As someone asks for a release, we cut it. - We run the generator by having a developer clone the repo, run `npm run generate`, and then submitting a PR with like 1344247584 changes. - After checking in that PR, someone has to submit a new release with releasetool. This will create a new tag. It is almost always semver major (see the fact that we're on v38). - The generator is somewhat monolithic. It works by blasting away the `src/apis` directory, and re-creating every API from scratch every time. This makes it easy to detect new APIs, and easy to detect removed APIs. Where we need to be - We want a bot that runs the generator(s) nightly. We should use `synthtoo
[BUG] service can't be used with `extends` as it declare `depends_on`
Description When trying to bring up a compose project that makes use of `extends` feature, I am getting the following error: [code block] Steps To Reproduce 1. Have a docker-compose.yml project with extends, like this: [code block] and the nginx/compose.yml: [code block] 2. `docker compose up` 3. See error: service "nginx" can't be used with `extends` as it declare `depends_on` Compose Version [code block] Docker Environment [code block] Anything else? _No response_
next/image on node 16 give SIGSEGV
What version of Next.js are you using? 10.1.3 What version of Node.js are you using? 16.0.0 What browser are you using? Chrome, Firefox What operating system are you using? macOS 11.2.3 How are you deploying your application? next dev Describe the Bug Mac Mini M1, Node 16 next start crashes hitting next/images Already nuked node_modules and locks after updating node version [code block] Expected Behavior To work :) To Reproduce Use a simple next/image on a next.js project. Either using js or TS does not change the behavior
Bug: too hard to fix "Cannot update a component from inside the function body of a different component."
Note: React 16.13.1 fixed some cases where this was overfiring. If upgrading React and ReactDOM to 16.13.1 doesn't fix the warning, read this: https://github.com/facebook/react/issues/18178#issuecomment-595846312 ---- React version: 16.13.0 Steps To Reproduce 1. Build a time machine. 2. Go to the year 2017. 3. Build a huge application of 10K lines of code. 4. Get 80 (!) dependencies at package.json file including ones that become no longer maintained. 5. Update React to the latest version at February 27, 2020. 6. Get tons of errors that you don't know how to fix. 7. Tell your client that fixes are going to take unknown time and it's going to cost $$$ + days or weeks of investigation or we're going to get stuck with the outdated version of React and related libraries forever which will cost more $$$ but later. Being serious, the business I work for isn't interested on that at all. Obviously I'd never made it happen to get such warnings to appear if I'd get them earlier. Currently that's impossibly hard to make the errors to be fixed because I get them at many different cases and with a huge stack trace. I tried to fix at least one of the appearing errors and it already took a lot of time. I tried to debug some of used libraries but got no luck. Just one example: There we can notice the use of an outdated react-router, an outdated redux-connect (which I had to put to the project source to fix errors of outdated `componentWillReceiveProps` method), some HOCs created by r
Excessive memory usage when loading models with relations
Issue type: [ ] question [x] bug report [ ] feature request [ ] documentation issue Database system/driver: [ ] `cordova` [ ] `mongodb` [ ] `mssql` [ ] `mysql` / `mariadb` [ ] `oracle` [x] `postgres` [ ] `cockroachdb` [ ] `sqlite` [ ] `sqljs` [ ] `react-native` [ ] `expo` TypeORM version: [x] `latest` [ ] `@next` [ ] `0.x.x` (or put your version here) Steps to reproduce or a small repository showing the problem: If I load a list of models like this: [code block] With many elements (100 in my case) it gets up to 2+ GB of memory usage for the query, where if i load the model by itself, and then make separate queries for each relationship such as: [code block] And then map the results to the original list, the memory footprint is not even noticeable. <!-- To answer those questions you need to put "x" inside the square brackets, for example: [x] `mysql` [ ] `postgres` Also, please format your code properly (by taking code blocks into [code block]) !>
AWS CloudFormation limit of 200 maximum allowed resources
This is a Bug Report Description - What went wrong? After upgrading my project from 0.5.6 to 1.0.0 I attempted to deploy and received this error: `Template format error: Number of resources, 202, is greater than maximum allowed, 200` - What did you expect should have happened? I expect that this should have worked since there is no limitation on AWS that should forbid this, and it was working on 0.5.6. Serverless should break up the template resources automatically to make this possible. With the current method you are forced to break up the service, which should not be necessary. This causes problems with general project structure, custom domain mapping, and shared dependencies. - What was the config you used? The example config below will generate the error by creating 65 endpoints. [code block] - What stacktrace or error message from your provider did you see? `Template format error: Number of resources, 214, is greater than maximum allowed, 200` another possible error `Template may not exceed 460800 bytes in size.` Additional Data - _Serverless Framework Version you're using_: 1.0.2 - _Operating System_: Windows 10 x64 - _Stack Trace_: N/A - _Provider Error messages_: See above
Can't Delete User on Locally Deployed Supabase: 'Method Not Allowed' Error
Discussed in https://github.com/orgs/supabase/discussions/32900 <div type='discussions-op-text'> <sup>Originally posted by thejufo January 18, 2025</sup> Context: I've recently deployed Supabase locally on my machine, everything worked great until I tried to delete a test user in Supabase Studio `http://127.0.0.1:54323` auth section. Problem: When I attempt to delete the user, I get this error message: "Failed to delete selected users: API error happened while trying to communicate with the server.". After digging into it a bit, I noticed this seems to be related to the Studio itself. Here's a screenshot of the request: <img width="1512" alt="Screenshot 2025-01-18 at 12 50 47 PM" src="https://github.com/user-attachments/assets/9d077058-0940-4e3b-9df4-1a7f53b164d3" /> What I’ve Tried: I dug deeper into the source code and found where the delete request is handled. From what I can tell, it should work, but for some reason, it's not, Here’s the code snippet: <img width="857" alt="Screenshot 2025-01-18 at 12 52 13 PM" src="https://github.com/user-attachments/assets/dab1ba22-670d-4294-8016-a0bb573b706b" /> Question: Does anyone know what’s going on here? Is there some configuration I missed, or could it be a bug? I’d really appreciate any advice or ideas on how to fix this! </div>