Support ES6 modules export / ESM

It would be great if the Prisma Client JS generator would be compatible with ES6 modules out of the box.
Note: Related to prisma/prisma-client-js#175

@Yamboy1 See https://github.com/prisma/prisma/pull/4920

@Yamboy1 See https://github.com/prisma/prisma/pull/4920

@pantharshit00 Hi, Can we look at this again? This pull request cites NodeJS 10 as the reason, why this can't be supported. However, release 2.25.0 dropped support for Node 10, so maybe we can support this now?

@janpio #7053 is another case where missing native support for es-modules breaks prisma. If you try to use prisma db seed in an es-module project (as in type: module in the projects package.json, as f.e. in sveltekit or vite-projects), you'll end up with:
TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for /path-to-my-project/play-prisma-sqlite/prisma/seed.ts
    at new NodeError (node:internal/errors:329:5)
    at Loader.defaultGetFormat [as _getFormat] (node:internal/modules/esm/get_format:71:15)

if you follow the documentation for seeding via typescript. Or with:
> prisma db seed --preview-feature

Environment variables loaded from .env
Prisma schema loaded from db/schema.prisma
Running seed from "db/seed.js" ...
Result:
internal/modules/cjs/loader.js:1102
      throw new ERR_REQUIRE_ESM(filename, parentPath, packageJsonPath);
      ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: [redacted]/db/seed.js
require() of ES modules is not supported.
require() of [redacted]/db/seed.js from [redacted]/[eval] is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename seed.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from [redacted]/package.json.

    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1102:13)
    at Module.load (internal/modules/cjs/loader.js:950:32)
    at Function.Module._load (internal/modules/cjs/loader.js:790:14)
    at Module.require (internal/modules/cjs/loader.js:974:19)
    at require (internal/modules/cjs/helpers.js:92:18)
    at [eval]:4:16
    at Script.runInThisContext (vm.js:134:12)
    at Object.runInThisContext (vm.js:311:38)
    at internal/process/execution.js:77:19
    at [eval]-wrapper:6:22 {
  code: 'ERR_REQUIRE_ESM'
}
Error: Command failed with exit code 1: node -e "
console.info('Result:')

const __seed = require('./db/seed.js')
const __keys = Object.keys(__seed)

async function runSeed() {
[... rest is irrelevant as the require() in the runner is the problem]

if you use a simple js-file as require() isn't supported anymore.
You can, as a workaround, run the seed file manually but you'll loose the integration in the other prisma-cli-taks :/

Looking forward to having this support!

What worked for me, let me know if this works for you too:
package.json
{
  "name": "db-seed-esm-pkg",
  "type": "module",
  "devDependencies": {
    "@prisma/client": "2.30.3",
    "@types/node": "12.20.23",
    "prisma": "2.30.3",
    "ts-node": "10.2.1"
  },
  "dependencies": {
    "@prisma/client": "2.30.3"
  }
}

tsconfig
{
  "compilerOptions": {
    "module": "ESNext", // required!, needs to be ES6, ES2015, ES2020, ESNext, if not set errors with "ReferenceError: exports is not defined"
    "moduleResolution": "Node", // required!
    "esModuleInterop": true, // required!
    "strict": true, // optional but recommended
  },
}

script.ts
import type { Prisma } from "@prisma/client";
import PrismaClientPkg from "@prisma/client";

const PrismaClient = PrismaClientPkg.PrismaClient;

const prisma = new PrismaClient();

will error with ts-node script.ts with  TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts" for [...]/script.ts
works if using node --loader ts-node/esm script.ts!

@Jolg42 Yes, basically. I'm using node --experimental-specifier-resolution=node --loader ts-node/esm as it also enables importing ts-files into the seed-file.

works if using node --loader ts-node/esm script.ts!

@Jolg42 and @benbender This works for now, but just a heads up from https://github.com/TypeStrong/ts-node/issues/1007#issuecomment-917677011, --loader is on track for a breaking change soon.
My workaround is to avoid ts-node altogether and create an NPM script to compile the file with tsc directly, execute with node, and clean up after it's been executed:
"db-seed": "tsc prisma/seed.ts && node prisma/seed.js && rm prisma/seed.js"

This means my seed script in Prisma 3 looks like:
"seed": "npm run db-seed"

If anybody has a more elegant solution, I would love to hear about it.

I would love to somehow get ES module support in the generated prisma client. My use case is prisma-appsync on AWS lambda, and bundling with esbuild which only supports tree shaking of ES modules.

Hey @revmischa The big part of that bundle is coming from our runtime via getPrismaClient. That is the one (and only relevant) export that makes your bundle grow so big. You can't tree-shake that out. I understand that the bundle size is a problem. Luckily, this is something that we started working on.

We started enabling tree-shaking for some packages, but that hasn't reduced the prisma runtime size.
Bloating comes from engine-wrapper packages, which aren't tree-shaken. Doing that would be conclusive.
Additionally, we could have a review of our dependency sizes (since we bundle everything together).

This work was initiated in the scope of an upcoming preview feature called dataproxy:

This feature has a special runtime that is 200KB (minified) to work on Cloudflare workers.
This has enabled esm builds on our end, for us to start taking advantage of tree-shaking.
To be esm-ready, we will need to remove require, __dirname, __filename, and others.

So my next steps would be:

Apply the tree-shaking to engine-wrapper packages and see how that shrinks the runtime. Hopefully, that will help.
Then later in the future, we would refactor our code to remove all cjs-related stuff, like I mentioned above.

I have @prisma/engines and @prisma/engines-version etc. split out into a lambda layer so the size of them isn't really a huge issue for me (although at 90MB it's a bit heavy). The generated client is where the issue is for me.
Surely if the generated client has functions like prisma.table1.fetchMany() and prisma.table2.fetchMany() and my lambda function only calls table1.fetchMany() then the table2 stuff could be shaken out?

have @prisma/engines and @prisma/engines-version etc
Nice! :) However, from our analysis we also bundle everything from get-platform and fetch-engine, including their dependencies. But we don't use all of that.

Surely if the generated client has functions like prisma.table1.fetchMany() and prisma.table2.fetchMany()
That would be hard to do because it's dynamic, based on the generated DMMF.

Just curious, how big is your generated client? The DMMF can take quite a bit of space if you have a big schema.

Any idea on when this will be resolved? I've tried to get Prisma to run within a SvelteKit app that's built with Vite and it just doesn't work. I'll have to switch to a different ORM, which is really a shame.

Meanwhile, with SvelteKit i use this workaround:
// $lib/prisma.js

import Prisma from "@prisma/client";

export let prisma;

if (Prisma === undefined) {
	import("@prisma/client").then(({ PrismaClient }) => {
		prisma = new PrismaClient();
	});
} else {
	prisma = new Prisma.PrismaClient();
}

// in any endpoint

import { prisma } from "$lib/prisma";

// ...

import type { Prisma } from "@prisma/client";
import PrismaClientPkg from "@prisma/client";

const PrismaClient = PrismaClientPkg.PrismaClient;

const prisma = new PrismaClient();

I get
Module '"node_modules/@prisma/client/index"' has no default export.

and indeed, there is no default export.
The code actually works in runtime, but it's typed as any which obviously defeats the purpose

@bjoernbg
I use adapter-node/
This is part of my efficient config in package.json
{
	"type": "module",
	"scripts": {
		"dev": "svelte-kit dev --port 5000",
		"build": "svelte-kit build"
	},
	"dependencies": {
		"@prisma/client": "^3.4.0"
	},
	"devDependencies": {
		"@babel/core": "^7.15.8",
		"@babel/eslint-parser": "^7.15.4",
		"@sveltejs/adapter-node": "^1.0.0-next.55",
		"@sveltejs/kit": "^1.0.0-next.193"
		"prisma": "^3.4.0",
		"svelte": "^3.44.1"
	}
}

Besides, my CI gh-action do npx prisma generate before yarn build (there are some reasons to use yarn on VDS).
Everything works well

@blocka do you have the same tsconfig settings?

@efiand
That's strange. When i tried running the built application with Prisma I got errors about the usage of things like __filename  and __dirname. I didn't investigate further because it seemed to be exactly what @millsp described as open todos further up in this discussion. I have since switched away from Prisma – even though I really liked it.

@bjoernbg
I received an error about the absence of the variable __ dirname too - but not because of Prisma, but because of an attempt to use fs.writeFile in the builded application. And this surprised me, because in the development mode, writing to files works, and the cjs application lies in the build directory, which in other aspects works (therefore I will not use SvelteKit  in all projects yet).

@efiand
that's strange, I rewrote my db-access to use Knex (with Objection.js), which works fine with SvelteKit.

@blocka is your workaround still working? It doesn't work for me.

Another workaround is to place a package.json inside prisma client generated directory with the following content.
{
  "type": "commonjs"
}

Maybe this file could be generated by prisma to make it work regardless the project packaging (CommonJS or ESM)

Another workaround is to place a package.json inside prisma client generated directory with the following content.
{
  "type": "commonjs"
}

Maybe this file could be generated by prisma to make it work regardless the project packaging (CommonJS or ESM)

This doesn't work for me in a Nuxt3 project.

Another workaround is to place a package.json inside prisma client generated directory with the following content.
{
  "type": "commonjs"
}

Maybe this file could be generated by prisma to make it work regardless the project packaging (CommonJS or ESM)

Yes I did precisely this for serverless stack - https://github.com/serverless-stack/serverless-stack/pull/1154

Nuxt 3 some problem
Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.

The code actually works in runtime, but it's typed as any which obviously defeats the purpose

@blocka I also get the same thing, but I modified the code to provide the right types as well.
import type { PrismaClient } from "@prisma/client"
import Prisma from "@prisma/client"

export let prisma: PrismaClient

if (Prisma === undefined) {
  import("@prisma/client").then(({ PrismaClient }) => {
    prisma = new PrismaClient()
  })
} else {
  prisma = new Prisma.PrismaClient()
}

Just ignoring the IDE error seems less than ideal, but separating it into it's own file hides it at least, and it works at runtime.

this is how I'm using prisma with ESM so far:
package.json
{
  "type": "module",
  "engines": {
    "node": "18.x" // using latest node 18
  },
  "dependencies": {
    "@prisma/client": "3.12.0"
  },
  "devDependencies": {
    "prisma": "3.12.0",
    "typescript": "4.6.3"
  }
}

tsconfig.json
{
  "compilerOptions": {
    "target": "es2022",
    "module": "ES2022",
    "moduleResolution": "node", // waiting for typescript 4.7 then switch to "nodenext"

    "strict": true,
    "esModuleInterop": true
  }
}

import default from @prisma/client
import pkg from '@prisma/client';

const { PrismaClient } = pkg;
const prisma = new PrismaClient();

and now run script with node without any loader flag
node dist/index.js

Hi every one i'm also using this workaround to get things work so far:
import pkg from '@prisma/client';
const { PrismaClient } = pkg;
const prisma = new PrismaClient();
This is my tsconfig:
{
"compilerOptions": {
"target": "es6",
"lib": [
"esnext"
],
"module": "es6",
"moduleResolution": "node",
"sourceMap": true,
"outDir": "dist",
"removeComments": true,
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"strict": true,
"skipLibCheck": true
}
}
And my package.json:
{
"name": "test",
"version": "1.0.0",
"description": "test",
"type": "module",
"main": "server.ts",
"repository": "unknown",
"author": "unknown",
"license": "GPL-3.0-or-later",
"private": true,
"dependencies": {
"@prisma/client": "3.12.0",
"cors": "^2.8.5",
"dotenv": "^16.0.0",
"express": "^4.17.3"
},
"scripts": {
"build": "yarn tsc",
"dev": "concurrently "yarn tsc --watch" "nodemon -q dist/server.js"",
"start": "node ./dist/server.js"
},
"devDependencies": {
"@types/express": "^4.17.13",
"@types/node": "^17.0.25",
"concurrently": "^7.1.0",
"nodemon": "^2.0.15",
"prisma": "^3.12.0",
"ts-node": "^10.7.0",
"typescript": "^4.6.3"
}
}
Node version: 16.4.2
Prisma version: 3.12.0
Now my question for you is this one, this workaround or other workarounds are good to bring to production an application or it's better to don't use module ES6 untile it will be fully supported?

Any idea how I can fix this?
Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import '/my-lib/node_modules/@prisma/client' is not supported resolving ES modules imported from /my-lib/dist/prisma-generator.js
The line in question:
import { DMMF as PrismaDMMF } from '@prisma/client/runtime';
tsconfig.json:
{
  "compilerOptions": {
    "module": "ESNext",
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "lib": ["es2020", "DOM"],
    "target": "ES2020",
    "noImplicitAny": true,
    "moduleResolution": "Node",
    "declaration": true,
    "sourceMap": true,
    "strict": true,
    "resolveJsonModule": true,
    "outDir": "./lib",
    "rootDir": "./src",
    "typeRoots": ["src/types.ts"],
    "skipLibCheck": true,
    "experimentalDecorators": true
  },
  "include": ["./src/**/**/*.ts"]
}

also:
 "type": "module"

Here's another workaround that worked for me. It's similar to some of the others posted above, maintains typing, and doesn't require a dynamic import.
import Prisma1 from "@prisma/client";
import * as Prisma2 from '@prisma/client';

const Prisma = Prisma1 || Prisma2;
export const prisma = new Prisma.PrismaClient();

Wow, this topic is from March 2020. Is there a reason why Prisma doesn't fix this? It seems less approachable to some (me encluded) if we need to do workarounds like this.

Hey all, sorry for the delay on this one.  This issue is definitely on our radar, but we're still a small team and there's lots of issues competing for our attention.
I thought I understood the problem but like many things in life, I don't... 😅
This appears to work for me:
index.js
import { PrismaClient } from "@prisma/client"
const prisma = new PrismaClient()

async function main() {
  console.log(await prisma.user.findMany())
}

main().catch((err) => console.error(err))

prisma/prisma.schema
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id    Int    @id
  first String
  last  String
}

package.json
{
  "name": "issue-5030",
  "version": "1.0.0",
  "type": "module",
  "devDependencies": {
    "prisma": "3.15.1"
  },
  "dependencies": {
    "@prisma/client": "3.15.1"
  }
}

$ node index.js
[]

What am I missing? Thanks!

@matthewmueller - this seems to work for me
index.js

import Prisma1, * as Prisma2 from "@prisma/client";

const Prisma = Prisma1 || Prisma2;
export const prisma = new Prisma.PrismaClient();

@jesperordrup what is the error that you're seeing? I'm not able to reproduce this currently.

index.js
import { PrismaClient } from "@prisma/client"
const prisma = new PrismaClient()

async function main() {
  console.log(await prisma.user.findMany())
}

main().catch((err) => console.error(err))

prisma/prisma.schema
What am I missing? 😎

Change your index to a ts file, and you'll get Module '"@prisma/client"' has no exported member 'PrismaClient'.ts(2305) while importing.

I just tried and was able to reproduce @omar-dulaimi's issue. ESM has tighter restrictions over resolving requires than Node.js does, so you'd need to do:
import { DMMF as PrismaDMMF } from<EMAIL_ADDRESS>
Also, I'd love to know why you need to reach this deep into our runtime sweat_smile Maybe we can expose what you need higher-level.
If you have any other ESM problems, please post them!

I have tried your suggestion and many others before but none worked. So at its time, I had to manually bundle the code I needed.

Also, I'd love to know why you need to reach this deep into our runtime sweat_smile Maybe we can expose what you need higher-level.

I build generators for the community, and sometimes some libraries I need use ESM only, so I would be forced to change the whole project to ESM, which did not work due to that failing Prisma import.

Been literally trying to solve this for hours, and still unable to get this to work 👎

@multiplehats were you able to solve this ? i'm having the same issue with the same setup :(

@multiplehats were you able to solve this ? i'm having the same issue with the same setup :(

Gave up. I got it working in dev, but not on prod.
Decided to just include Prisma directly in my app. And work around it, until I have to create microservices.

Part of the trouble seems to be these __dirname references. When compiling the Prisma client into an ESM bundle with Rollup, and then run the resulting bundle, Node throws a ReferenceError, because __dirname is not defined in ESM, and the stack trace points to these lines.
I found this spot here that seems to do some work to fall back on other APIs if __dirname is not defined. Perhaps something similar might be done for the other __dirname calls?

This is my ESM __dirname equivalent:
import { fileURLToPath } from 'url'

const dirname = fileURLToPath(new URL('./', import.meta.url))

The reason these __dirnames exist is so that native binaries can be detected by Vercel's pkg trickery (https://github.com/vercel/pkg#detecting-assets-in-source-code). Just removing the __dirname with something else would break that asset detection and therefore break Prisma's compatibility with Vercel. The question is if those lines at https://github.com/prisma/prisma/blob/main/packages/engines/src/index.ts#L62 can somehow be included in a way that doesn't break Vercel compatibilty and also works with ESM...
In the meantime, if you want to use Prisma in an ESM module, one approach could be something like this actually:
import { createRequire } from 'module';
const require = createRequire(import.meta.url);
const { PrismaClient } = require('@prisma/client');

@katywings solution unfortunately has no type safety. The solution I came up with for my monorepo database package is quite a hack, but it works with SvelteKit and Next.js simultaneously. I created a lib/prisma.ts in my database package and in my src/client.ts I import the PrismaClient from there instead of @prisma/client.
import type { PrismaClient as ImportedPrismaClient } from '@prisma/client';
import { createRequire } from 'module';

const require = createRequire(import.meta.url ?? __filename);

const { PrismaClient: RequiredPrismaClient } = require('@prisma/client');

const _PrismaClient: typeof ImportedPrismaClient = RequiredPrismaClient;

export class PrismaClient extends _PrismaClient {}

I made my life easier with some additional TS magics
~/utils/cursed.ts
import { createRequire as _createRequire } from 'module'
export const createCursedRequire: (path: string | URL) => <TShape>(id: string) => TShape = _createRequire

and now you can do
import type { PrismaClient as ImportedPrismaClient } from '.prisma/bancho.py'
import { createCursedRequire } from '~/utils/cursed'
const require = createCursedRequire(import.meta.url ?? __filename)
const { PrismaClient } = require<{ PrismaClient: typeof ImportedPrismaClient }>('.prisma/bancho.py')

Today, I've been working to migrate our apollo-server v3 project to apollo-server v4 because v3 will be deprecated in October.
I just found that this issue keeps us back from upgrading to apollo v4 because it uses ESM by default.
Hope we have this support as no 1. ORM in the world 🚴♂

This just came up for me rather unexpectedly after upgrading from Prisma 4.13 to 1.14. The hack by @mkreuzmayr worked, and I'm very thankful for that. How can this happen all of a sudden?

The reason these __dirnames exist is so that native binaries can be detected by Vercel's pkg trickery (https://github.com/vercel/pkg#detecting-assets-in-source-code). Just removing the __dirname with something else would break that asset detection and therefore break Prisma's compatibility with Vercel. The question is if those lines at https://github.com/prisma/prisma/blob/main/packages/engines/src/index.ts#L62 can somehow be included in a way that doesn't break Vercel compatibilty and also works with ESM...

Couldn't that be an easy config specific for those users? A plugin/a flag to set up somewhere when using Prisma if you expect to use it with Vercel?
Breaking all esm environments just for Vercel users seems radical.

Hey everyone :wave:, I am happy to announce that we have started work to bring official support for ESM. Supporting ESM is a pretty big change, and we are super excited about it. The work is already pretty advanced and we are interested to learn how this will work in the real world. That's where we need you!
Could you give this a try and give us your feedback? Here's the instructions:

Install this integration version in your project

<EMAIL_ADDRESS><EMAIL_ADDRESS>

Try it out locally, run your tests, deploy your project.
Give your feedback and observations in this issue.

Thank you!
(If you are interested, here's the PR)

Hoping to see the changes here reach General Availability. With the advent of Full-stack frameworks like SvelteKit and Next, having Prisma support ESM greatly helps with the DX.

Any news about ESM support?

Nothing yet, but it's definitely on our list to look at again soon. We are currently building out some things that are necessary, and some other things that will greatly benefit from having ESM - so it's coming.

Had to install this branch which is a whole version behind to get things working with ESM
https://github.com/prisma/prisma/pull/19184
Hoping for first-class ESM support soon :)

Yeah, i also like to use prisma in my hobby project, and soon i'm gona hit the deploy, but it was devastating when i just casually tried solid-start build and start and suddenly just hit me with this error. The solid-start also in experimental phase but i loved solidjs so much i wanted to create a webapp with it. My experiences was fair at this point. I'm hope this will be fixed soon because also working with prisma was okay and it delivered a very nice developer experience. I'm a little bit scared of the other issues as well with the edge network. :/

If the ESM basic support is there, how about gating the feature behind an experimental flag on the latest branch?
This pattern has been pretty common and successful in many projects (e.g. Chrome's chrome://flags)

It's not there right now, the branch others linked to is multiple months old and now has a whole wall of conflicts. We had used that branch to get feedback in https://github.com/prisma/prisma/issues/5030#issuecomment-1565181377, but we also got some reports of things not working perfectly in https://github.com/prisma/prisma/discussions/19564.
Putting it behind an experimental flag will require us fixing all of these - and then also keep maintaining it (as the same conflicts would come back). We will properly fix this instead, and then aim to properly merge and include it in Prisma.

Is there a way to get this working in remix and vite until the official esm version is released?

Please open an issue about your concrete problem @Mxs2019, then we can potentially figure out how to make it work.

Bumping this in case it helps prioritize on the roadmap :)

This branch throws a lot of errors when used in server actions with the recently released Next 14. Throwing in the towel here, gonna migrate to Drizzly :( appreciate all the work you folks have done to try and get this working.

Hey @faizan-ali, we're sorry to see you go. For what is worth, ESM is currently on our agenda and I am working on reviving my old PR. Thanks for the feedback on Next 14, I will make sure to take a look. I will share another integration version again when it's ready in a few days.

I am generating client on different output directory & faced Directory import not supported issue in my Remix v2 project. probably due to no ESM support as it was working in V1 with cjs flag in remix config.
Then I exported my client as mentioned following, which resolved the issue & build was successful. But it is not type safe & lot of linting errors without intellisense support.  I migrated to Remix v2 to make things faster but not stuck with Prisma :| .
import * as test_db from "@myclientdirectory/prisma/test_db";

module.exports = test_db;

Hope ESM support will be available soon for Prisma.

I am generating client on different output directory & faced Directory import not supported issue in my Remix v2 project. probably due to no ESM support as it was working in V1 with cjs flag in remix config. I am also getting Error: Dynamic require of "tty" is not supported issue if directly importing from my custom client directory generated in node_modules folder.
Then I exported my client as mentioned following, which resolved the issue & build was successful. But it is not type safe & lot of linting errors without intellisense support. I migrated to Remix v2 to make things faster but not stuck with Prisma :| .
import * as test_db from "@myclientdirectory/prisma/test_db";

module.exports = test_db;

But strange thing is that this issue is open since last 3 years. As of now, it was easy to work with Prisma without ESM support as many frameworks were supporting cjs, but now frameworks like Remix v2 need ESM packages, so it is really a needed feature.
Hope ESM support will be available soon for Prisma.

We're having the same issue in our Nx monorepo, we can't have multi-client support using ESM.
We no longer use Prisma, in favor of other ORMs.

Hello! Would just like to add that we would like to use Prisma for accessing two different databases with different schemas. Hence, we would like to generate two different Prisma clients, but we're also having issues with the generated code as it's not ESM. We will still go ahead and use Prisma for one of our databases, and hopefully we can also use it for the second one as soon as there is support for it.

Hello! Would just like to add that we would like to use Prisma for accessing two different databases with different schemas. Hence, we would like to generate two different Prisma clients, but we're also having issues with the generated code as it's not ESM. We will still go ahead and use Prisma for one of our databases, and hopefully we can also use it for the second one as soon as there is support for it. Optionally we've considered wrapping the second prisma client in an NPM package, but we're hoping we don't have to do that.

have you tried createRequire mentioned above? We got away with this exact use case.

Hey @faizan-ali, we're sorry to see you go. For what is worth, ESM is currently on our agenda and I am working on reviving my old PR. Thanks for the feedback on Next 14, I will make sure to take a look. I will share another integration version again when it's ready in a few days.

Bumping this again :) I switched to Drizzle but recently pulled in Prisma for a different project.  Thank you for all the work you've done!

Hello! Would just like to add that we would like to use Prisma for accessing two different databases with different schemas. Hence, we would like to generate two different Prisma clients, but we're also having issues with the generated code as it's not ESM. We will still go ahead and use Prisma for one of our databases, and hopefully we can also use it for the second one as soon as there is support for it. Optionally we've considered wrapping the second prisma client in an NPM package, but we're hoping we don't have to do that.

have you tried createRequire mentioned above? We got away with this exact use case.

No, we would prefer to be able to do this without the use of TS magic hehe, but thanks for the pointer 😉

Hello! Would just like to add that we would like to use Prisma for accessing two different databases with different schemas. Hence, we would like to generate two different Prisma clients, but we're also having issues with the generated code as it's not ESM. We will still go ahead and use Prisma for one of our databases, and hopefully we can also use it for the second one as soon as there is support for it. Optionally we've considered wrapping the second prisma client in an NPM package, but we're hoping we don't have to do that.

have you tried createRequire mentioned above? We got away with this exact use case.

No, we would prefer to be able to do this without the use of TS magic hehe, but thanks for the pointer 😉

After further investigations it seems we need to wrap it somehow anyway.. Sadly, with the approach described above, I am able to import the client, but not import the generated enums..

Personally using Express in Node, would really appreciate some ESM support as it has been out for quite some time now.
Most libraries are compatible, except for Prisma :(
Thanks for all the great work otherwise guys, love Prisma alot!

Hello! Would just like to add that we would like to use Prisma for accessing two different databases with different schemas. Hence, we would like to generate two different Prisma clients, but we're also having issues with the generated code as it's not ESM. We will still go ahead and use Prisma for one of our databases, and hopefully we can also use it for the second one as soon as there is support for it. Optionally we've considered wrapping the second prisma client in an NPM package, but we're hoping we don't have to do that.

have you tried createRequire mentioned above? We got away with this exact use case.

No, we would prefer to be able to do this without the use of TS magic hehe, but thanks for the pointer 😉

https://nodejs.org/api/module.html#modulecreaterequirefilename
createRequire is a nodejs thing, not TS magic. All types are generated by prisma.

Jumping in to see if there are any possible updates on this? :)

Looks like this is where the buck stopped: https://github.com/prisma/prisma/pull/21858

So, currently there's no way to use Prisma with SvelteKit. Am I right?
I've tried https://gitpkg.now.sh/prisma/prisma/packages/client?integration/feat/client/esm-2, with no luck.

@kissge It is possible to use Prisma from ESM project, you can check Shopify Remix template for a working example.

I was under the impression that one of the issues with Prisma+ESM had to do with trying to bundle Prisma with ESM code for production, which may cause runtime errors when Prisma calls CJS code that the bundler couldn't quite figure out on its own how to replace correctly. At the moment, the Prisma client must be externalized, meaning more modules that need moved into a production environment at deploy time, and that can get messy.

I'm no expert either, but my production build is still being bundled to CommonJS because (as far as I understand it) the Prisma client relies on globals like __dirname that used to be part of Node but in ESM have been moved to import.meta.dirname. See: https://stackoverflow.com/questions/46745014/alternative-for-dirname-in-node-js-when-using-es6-modules
So until that's fixed (work which seemed to have started here: https://github.com/prisma/prisma/pull/21858/files) production bundles still need to be CommonJS, which makes things like root-level async/await not possible. Again, as far as I understand it :-)

So, is there a workaround/solution for this issue currently?
I'm using a monorepo configuration with pnpm workspaces right now, with Nuxt.
So, the project is structured as such:

Nuxt frontend
Backend
Shared prisma client (https://github.com/igolka97/shared-prisma-client-example)

I can't figure out how to make the client work with the production version of the frontend properly though.
Weirdly, pnpm run dev works, but not pnpm start.
One hack I've found is just generating two clients, but one in /tmp/prisma-engines
generator client_docker {
  provider      = "prisma-client-js"
  output        = "/tmp/prisma-engines"
  binaryTargets = ["native", "rhel-openssl-1.0.x", "debian-openssl-3.0.x", "linux-musl-openssl-3.0.x"]
}

like this, and having the following server.js
import { fileURLToPath } from 'url';
import { dirname } from 'path';

// Define the __dirname and __filename variables globally
global.__dirname = dirname(fileURLToPath(import.meta.url));
global.__filename = fileURLToPath(import.meta.url);

// Import the server module
import('./.output/server/index.mjs');

and using node server.js to start the application.
This feels like a very hacky solution though..

Haven´t had time to verify if it still works, but you could try this workaround I posted here some time ago.

On nuxt3 I found, after half a day......, that it simply works using
import { PrismaClient } from<EMAIL_ADDRESS>instead
import { PrismaClient } from '@/prisma/generated/postgres'

Prisma, after 4 years, still not being able to generate ESM and the entire ecosystem moving to ESM is creating so many issues.
I have hit a bad road block because I unfortunately need 2 Prisma clients, and it's making me just wanting to rm-rf Prisma https://github.com/withastro/astro/issues/11190

A workaround with working types.
// my-prisma.d.ts
export {};

import * as PrismaNamespace from "@prisma/client";

declare global {
    namespace globalThis {
        export import Prisma = PrismaNamespace;
    }
}

// my-prisma.ts
const require = module.createRequire( import.meta.url );

const Prisma = require( "@prisma/client" );

global.Prisma = Prisma;

in some environments you will be need to add my-prisma.d.ts to tsconfig.json

Sounds like this is related because the client doesn't support tree shaking? I just imported a couple enums from @prisma/client in my Next client component, and by doing so it caused the entire db schema defined in .prisma/client/index-browser.js to be bundled with the page. Aside from the extra 50kb, leaking my db schema to the public is a concern.

Sounds like this is related because the client doesn't support tree shaking? I just imported a couple enums from @prisma/client in my Next client component, and by doing so it caused the entire db schema defined in .prisma/client/index-browser.js to be bundled with the page. Aside from the extra 50kb, leaking my db schema to the public is a concern.

Just had a similar experience, plus the fact that importing a few enums caused the prisma/client lib to be bundled with my code, which causes the ReferenceError: __dirname is not defined in ES module scope error. I can only import the type of the enum, then use the raw strings as values.
For example, for this enum:
enum PullRequestState {
  OPEN
  MERGED
  CLOSED
}

This breaks:
import { PullRequestState } from "@server/db";

const stateForPullRequest = (event: PullRequestEvent): PullRequestState =>
    event.pull_request.state == "open"
        ? PullRequestState.OPEN
        : event.pull_request.merged == true
          ? PullRequestState.MERGED
          : PullRequestState.CLOSED;

But this works:
import type { PullRequestState } from "@server/db";

...

const stateForPullRequest = (event: PullRequestEvent): PullRequestState =>
    event.pull_request.state == "open"
        ? "OPEN"
        : event.pull_request.merged == true
          ? "MERGED"
          : "CLOSED";

My workaround:
Copy each enum as they're needed into the frontend code and write tests that ensures it still matches the types exported by @prisma/client, without actually importing any runtime code from @prisma/client.

This workaround resolved the module not found for me while running Bun, Astro and Prisma together. There's an accelerate-based example which imports PrismaClient directly but that didn't work for me. We're using prisma in other projects and haven't run into this issue before.

Create a wrapper util that utilizes createRequire:

// src/util/orm.js
import { createRequire } from 'module';
const require = createRequire(import.meta.url);

const { PrismaClient } = require('@prisma/client');

const prisma = new PrismaClient();

export default prisma;

Use prisma in Astro actions file:

// src/actions/groupActions.js
import { prisma } from '../util/orm';

export async function fooBar(bazBax) {
  try {
    const hello = await prisma.verb...

The main change here is createRequire: https://nodejs.org/api/module.html#modulecreaterequirefilename

I've been experimenting with Prisma and Deno 2.0 and I encountered the same problem. However it can be fixed not only by changing the Prisma Client files to ESM, but also by renaming the generated files (and updating imports) to .cjs.
If I understand correctly both Deno 2.0 and Node in ESM mode still support CommonJS imports in .cjs files.

https://nodejs.org/api/esm.html#enabling
https://docs.deno.com/runtime/fundamentals/node/#commonjs-support

Might it be a "quick fix", to have an option to generate the same Prisma Client output as now, but with .cjs extensions?

Ideally the Prisma generator would have an option to specify the module format of the generated client.
ESM support is crucial as the community is continuing to drop CJS in favor of ESM.

Strange thing is that this issue is still active since last 4.5 years. No action or plan shared by official prisma team. May be they have already supported its ESM to their enterprise customers as it is not easy to live without ESM support now.
Open source community may need to fix it by their own without relying on Prisma team. I can spent time to fix it but I am not an expert in module bundling development.

Adding to the noise here to reiterate how important esm support is. It's a shame that #21858 is now over a year old (not including the three years of previous PRs that preceded it), and 924 commits behind main :(

Adding to the noise here to reiterate how important esm support is. It's a shame that #21858 is now over a year old (not including the three years of previous PRs that preceded it), and 924 commits behind main :(

Great to see efforts made by that person to raise that PR, but shame that no one even responded to that PR. Really very sad. :(
Prisma team or code owners, please check and approve this PR https://github.com/prisma/prisma/pull/21858.

I've been experimenting with Prisma and Deno 2.0 and I encountered the same problem. However it can be fixed not only by changing the Prisma Client files to ESM, but also by renaming the generated files (and updating imports) to .cjs.
If I understand correctly both Deno 2.0 and Node in ESM mode still support CommonJS imports in .cjs files.
* https://nodejs.org/api/esm.html#enabling

* https://docs.deno.com/runtime/fundamentals/node/#commonjs-support

Might it be a "quick fix", to have an option to generate the same Prisma Client output as now, but with .cjs extensions?

I got this working with a short script:
#!/usr/bin/env deno --allow-write --allow-run --allow-read

// clear the `generated` folder
try {
  await Deno.remove("./generated", { recursive: true });
} catch (error) {
  if (error instanceof Deno.errors.NotFound) {
    console.log("The 'generated' folder does not exist, skipping removal.");
  } else {
    throw error;
  }
}

// run deno run --allow-read --allow-env --allow-write npm:prisma migrate dev --name init
const command = new Deno.Command("deno", {
  args: [
    "run",
    "--allow-read",
    "--allow-env",
    "--allow-write",
    "--allow-sys",
    "--allow-run",
    "npm:prisma",
    "migrate",
    "dev",
    "--name",
    "init",
  ],
  stdout: "inherit",
  stderr: "inherit",
});

await command.output();

// in the `generated` folder name all `.js` files to `.cjs` recursively
async function renameJsToCjs(dir: string) {
  for await (const dirEntry of Deno.readDir(dir)) {
    const fullPath = `${dir}/${dirEntry.name}`;
    if (dirEntry.isFile && dirEntry.name.endsWith(".js")) {
      const newPath = fullPath.replace(".js", ".cjs");
      await Deno.rename(fullPath, newPath);
    } else if (dirEntry.isDirectory) {
      await renameJsToCjs(fullPath);
    }
  }
}

await renameJsToCjs("./generated");


Provide example of testing a Future in the unittest library level docs

This issue was originally filed by @sethladd

The docs at the top of http://api.dartlang.org/docs/bleeding_edge/unittest.html are great. However, because Futures are all over the place in Dart, we can really help by providing a short example of how to test a Future.

This issue has been moved to dart-lang/test#184.


[Bug]: circular dependency problem

Version
System:
    OS: macOS 14.2.1
    CPU: (12) arm64 Apple M2 Pro
    Memory: 83.97 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Browsers:
    Chrome: 122.0.6261.112
    Safari: 17.2.1
    Safari Technology Preview: 17.4
  npmPackages:
    @rsbuild/core: ^0.4.14 => 0.4.15
    @rsbuild/plugin-node-polyfill: ^0.4.14 => 0.4.15
    @rsbuild/plugin-react: ^0.4.14 => 0.4.15
    @rsbuild/plugin-styled-components: ^0.4.15 => 0.4.15

Details
webpack5 build is ok, but rspack will cause circular dependency problem, the reason is that webpack5 will change import { defineLocale } from 'packageA' to import { defineLocale } from './src/locale.js', but rspack will not, so circular dependency problem occur
ps: webpack4 is also not ok
i wonder if there has some option to make this behavior same as webpack
Reproduce link
https://github.com/jayjliang/rsbuild-demo
Reproduce Steps
yarn
cd ./packages/package-b
yarn dev
yarn dev:webpack

newTreeshaking solve this problem，try it

newTreeshaking solve this problem，try it

ok, already try newTreeshaking, but the build time increase from 10s to 1.46min, I will use some tools like Rsdoctor to analyse the build time

Do you mean the same repo?

Please file another issue if the problem couold not be solved.


Jadeite Alpha 1.0 doesn't allow logins if ROWAN_HOME is not set

I changed the installation scripts for Issue #107 and when I went to do a test login, I get the following error:

I can finesse this for testing, but this should be changed before the drop and I won't be able to merge my work into the master branch until this is fixed, either.

I'll change the $ROWAN_HOME check to a $ROWAN_PROJECTS_HOME check.

but for Jadeite to work, doesn't this require code that has not been checked into master?


Update default GitHub Actions Danger Token to Secret

Why
Template's default has GitHub Actions workflows using DANGER_GITHUB_API_TOKEN as ${{ github.token }} which will result in 403 when Danger try to comment on a PR.
Acceptance Criteria
Workflows should have DANGER_GITHUB_API_TOKEN as Secrets to avoid confusion for users, so that user knows to put the Secrets correctly.
  DANGER_GITHUB_API_TOKEN: ${{ secrets.DANGER_GITHUB_API_TOKEN }}

Who Benefits?
New user of the template.

This is solved if user had given permission to Actions to allow writing on PR.
Improved instruction might be needed.


Add config to build Auth release on GCB

Release note:
Add a config file for running Auth release builds on Google Container Builder.

/lgtm
Need one more approver
/assign @lookuptable

/lgtm

/approve


wrong cursor position when using cmder in vscode

VSCode Version:1.31.1
OS Version: Win 10 1809

Steps to Reproduce:
As shown in the figure, there's a mismatch when moving the cursor to the left and back. The problem might be related to the clink injection part of the cmder script.

The related settings are
"terminal.integrated.shell.windows": "C:\WINDOWS\System32\cmd.exe",
"terminal.integrated.env.windows": {"CMDER_ROOT": "C:\Users\xxx\apps\cmder"},
"terminal.integrated.shellArgs.windows": [
"/k",
"C:\Users\xxx\apps\cmder\vendor\test.bat /f"
]
I understand this might not be the best place to ask. But I wish to get some help about how to fix this since many vscode&cmder users would come across this rep.

Does this issue occur when all extensions are disabled?: Yes/No
Yes

I managed to solve the problem by replacing the lambda λ prompt with dollar $. BTW, the same mismatch happens for bash/powershell/cmd as long as you use λ as the prompt symbol. It might not be a good idea for them to use λ. But it seem to be a issue for vscode. anyway, it doesn't matter as long as you can replace the symbol

Looks like a duplicate of https://github.com/xtermjs/xterm.js/issues/1709


Still can't use this if PG extensions are in use

e.g.:
ActiveRecord::StatementInvalid: PG::UndefinedFile: ERROR:
could not open extension control file "/usr/lib/postgresql/13/share/extension/citext.control":
No such file or directory

why can't these be shipped?

Any workarounds for the moment? This issue is blocking from updating to PostgreSQL v14 since there's no legacy image for v14 (circleci/postgres).
I tried adding the postgresql-contrib package, but it seems not to solve the problem. Any suggestions?
- run:
    name: Add postgresql-contrib package
    command: |
      sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
      wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
      sudo apt-get -y update
      sudo apt-get -y install postgresql-contrib

PS: Thank you @joergschiller for the PR! I hope it gets merged soon 🙂

Same here for PG 10.18 and pgcrypto (default contrib extension).
postgres=# create extension pgcrypto;
ERROR:  could not open extension control file "/usr/lib/postgresql/10/share/extension/pgcrypto.control": No such file or directory

Thanks for looking into this @joergschiller.

We are experiencing the same issues.
We have a Ruby build (for our Rails app) which uses cimg/postgres:11.13. Both this and postgis variant yielded the following error in regards to the missing CITEXT extension.
ActiveRecord::StatementInvalid: PG::UndefinedFile: ERROR:  could not open extension control file "/usr/lib/postgresql/11/share/extension/citext.control": No such file or directory

Prior to this we were using the non-convenience images (circleci/postgres:11.12) and it functioned with no issues. I am assuming it came packaged with the extensions.
Please advise on the best path forward to address this. The roadblock is preventing us from updating to the new convenience images.

Same here too. We're just trying to enable btree_gist for PostGIS if it doesn't exist for our tests. Specifically:
CREATE EXTENSION IF NOT EXISTS btree_gist WITH SCHEMA public;

gets us:
ERROR:  could not open extension control file "/usr/lib/postgresql/10/share/extension/btree_gist.control": No such file or directory

So 👍 to needing this to move away from circleci/postgres*postgis to cimg/postgres:10.18-postgis

Same issue here on version 11.13.
Failed on the first extension creation:
ERROR:  could not open extension control file "/usr/lib/postgresql/11/share/extension/hstore.control": No such file or directory

Those other extensions are also used:

pg_trgm
uuid-ossp

This is being worked on. Updated images will be rolled out soon.

This is being worked on. Updated images will be rolled out soon.

Great news, @felicianotech! One quick note: this was was raised in the beta-test thread in your forums months ago. Perhaps you can feed that back to a retro -- if you have community spaces like your forums, then please look at the feedback and act on it where appropriate!

@imajes Correct. I just took a look and found your Discuss post on when this was mentioned. In that same thread I mentioned taking a look followed by the GA announcement. Clearly I dropped the ball there.
Thank you for reintroducing this here as we can see by the +1s, others are having this same issue.

Images have been updated to include extensions that are part of the PostgreSQL Contrib package.
Can people confirm on your end that the errors went away?

Images have been updated to include extensions that are part of the PostgreSQL Contrib package.
Can people confirm on your end that the errors went away?

Our postgres step completed without issue. I would say the extensions error went away.
Although I have now encountered a different issue with the convenience ruby image and the mismatch of major node versions between the deprecated and convenience images. But that's an issue for a different repo :)
Thanks for the quick turnaround!

@felicianotech extensions hstore and pgcrypto are working for me too, thanks! 🎉
PS: Now I have data to compare tests running on cimg/postgres:14 vs. circleci/postgres:13.4-ram. It seems like testing times have increased from ~15s to an average of ~23s. I can open a separate issue with more details if it makes sense. Maybe it is helpful to have a -ram variation of the image 🙂

Awesome. I'm going to consider this resolved at this point. I want to thank @ joergschiller for the PR that brought in all the contrib extensions, thus solving this issue.
@JoseLion Yes please open an issue on this and share whatever data you may have. I'm also curious as to scenarios where maybe running in RAM can be a negative.


Multi-argument custom query invalidation doesn't seem to work

In a project, I have lists of entities called "hypotheses" that need to be refreshed via live queries. These lists are fetched using the following query:
type Query {
  hypotheses(
    project: ID!
    law: Int
    filters: ListFiltersInput!
  ): HypothesisPage!
}

Hypotheses are tied to specific "laws" (identified by integers). The second argument law can be null which returns all hypotheses regardless of their laws.
I'm trying to invalidate based on a custom index that looks like this:
{
  field: "Query.hypotheses",
  args: ["project", "law"]
}

Here is the document I use on the frontend:
export const HypothesesQuery = gql`
  ${HypothesisPageFragment}

  query Hypotheses($project: ID!, $law: Int, $filters: ListFiltersInput!)
    @live {
    hypotheses(project: $project, law: $law, filters: $filters) {
      ...HypothesisPage
    }
  }
`;

Now when creating an hypothesis with a createHypothesis mutation (resolver is successfully called), the following invalidation doesn't work:
invalidate([
  `Query.hypotheses(project:"${project._id.toHexString()}",law:null)`,
  `Query.hypotheses(project:"${project._id.toHexString()}",law:${
    hypothesis.law
  })`
]);

(project._id.toHexString() has the correct value)
Any idea of what's going on? Thank you.

Ok by logging the generated indices, I can see what's going on. Here are some:
  'Query.hypotheses(project:"61008f309a516c36b4505363",law:"2")',
  'Query.hypotheses(project:"61008f309a516c36b4505363",law:"null")',
  'Query.hypotheses(project:"61008f309a516c36b4505363",law:"3")'

Non-string values seem to be cast to strings before generating the keys. I think this is a bug.

What behavior would you consider instead? If the type would implement a .toString() function you can customize how the thing is stringified 🤔

@n1ru4l Well since the base scalars are JSON-ish, you could use JSON.stringify for numbers, strings, null and booleans, and .toString() for other values. This would make the indices closer to actual GraphQL syntax. What do you think?

Why couldn't your id type implement a toString method?
class ID extends YourId {
  toString() {
    return this.toHexString()
  }
}


Force file removal in Windows _removeItem

unlink on posix ignores if a file is read only since it only needs write
permissions on the parent directory to remove it. To emulate this on
Windows, if a file is read only, unset the read only bit and then remove
it.

@swift-ci please test linux


fix(conf) drop lua_code_cache option

This option no longer works, but triggers a lot of support
questions.

Before merging this, I would be very much inclined to reproduce the errors (it should be fairly easy to reproduce), and keep track of them somewhere.

Spent some time on there, and init_worker not being run when lua_code_cache is false is our issue. A lot of modules initialized in init_worker should be initialized in init instead, but cannot because of lua-resty-worker-events iirc.
Regardless, considering the implications of disabling this directive and how limiting it is (lack of ngx.semaphore, FFI contexts, and the number of lua-resty modules depending on them), it might indeed be better to simply drop support for it, I concur.

Before merging this, I would be very much inclined to reproduce the errors (it should be fairly easy to reproduce), and keep track of them somewhere.

@thibaultcha I didn't fully understand what you meant by this? considering your follow up message, it it good to merge now? if not please elaborate on what you meant by the above.

@Tieske I meant to spawn a lua_code_cache disabled instance and see how it behave. While I very much like the idea of an instance on which developers can freely edit it without having the reload Kong, I think the trouble of maintaining such a convenience isn't worth the currently needed refactor  nor the potential limitations we could encounter in the future...
I say: merge!


gui: avoid displaying ideal clock odd values in report timing

Fix #4486

@maliberty One doubt here: these changes don't suppress the fanout number of the first node, they should?
There's also #4228 related to ideal clocks. I can refine the changes here when addressing the other issue.

The text report doesn't show the fanout but I don't see the harm in showing it.  It gives some sense of the eventual clock tree size.  If others feel differently it can be addressed in another PR.


discovery/kubernetes: Fix valid label selector causing config error

Label selector can be
"set-based"(https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)
but such a selector causes Prometheus start failure with the "unexpected
error: parsing YAML file ...: invalid selector: 'foo in (bar,baz)';
can't understand 'baz)'"-like error.
This is caused by the fields.ParseSelector(string) function that
simply splits an expression as a CSV-list, so a comma confuses such a
parsing method and lead to the error.
Use labels.Parse(string) to use a valid lexer to parse a selector
expression.
Closes #8284.
Signed-off-by: Alexey Shumkin<EMAIL_ADDRESS>

@brancz does this look right to you?

any feedback?

Sorry, it is a bit quiet due to the holidays period.
cc @olagacek does this look fine to you? thanks!


Release layout-linter Broccoli plugin ?

@GreatWizard the Broccoli plugin you wrote here works great 👌
Should we include it in this repo in some way?
Should we create a separate repo/module for this?
Should we not bother with this at all for now since it's too early and no one outside PD is actually using layout-linter right now?
ping @saintsebastian and @xcambar for reference

A second repo would be ideal, IMO


Release new version?

The current version on Pypi fails with new versions of python because it lacks https://github.com/real-yfprojects/sphinx-polyversion/commit/cb040a77cc4d167ce57139c82c67b77f6420afa7. Do you plan to push the latest code to Pypi?

Yes, I just released a new version. However it doesn't contain any new features.


GridFieldDetailForm: redirect to CMSEditLink if page not found

If you are editing a record inside a GridFieldDetailForm, depending on the list there is a chance that you can edit the record in a way that means it is no longer part of the GridField's list.
For example, if you are editing an ActiveItems GridField, filtered on Status = Active, then you can break the view you set Status to Inactive.
Right now, this throws an error after save and if you refresh you get a 4xx error.
I recommend that, if the record has a CMSEditLink() method, the system automatically redirects to that URL in such a case.

Was just looking for this functionality, looks like it’s been implemented in https://github.com/silverstripe/silverstripe-framework/pull/9655 😄


Handle deleted Fandom wikis

On Fandom, the wiki pmd-rt-archive.fandom.com has been deleted and now redirects to pokemon.fandom.com. However, Indie Wiki Buddy redirects pmd-rt-archive.fandom.com to the Mystery Dungeon Franchise Wiki, while it redirects pokemon.fandom.com to Bulbapedia. I believe this fact was overlooked when retrieving Main Page titles; the Main Page title of pmd-rt-archive.fandom.com should be "Pokémon_Mystery_Dungeon_Rescue_Team_Wiki" instead of "Pokémon_Wiki" (which is the Main Page title of pokemon.fandom.com).
This case made me wonder whether it is worth including dead Fandom URLs at all. For wikis that left Fandom and had the Fandom wiki closed, is it worthwhile for those wikis to be submitted so that old links could be pointed at the only existing wiki left? Or should Indie Wiki Buddy only concern itself with origin wikis that currently exist?
If Indie Wiki Buddy does preserve dead Fandom URLs as origins, I think they should at least be tagged, so that any kind of future automated scraping (like was done for Main Page titles) would be able to account for that.

Discovered a second instance of this: rayman.fandom.com is closed (in English), and appears to have been closed for several years. sitesEN.json currently lists Special:LanguageWikisIndex as the wiki's main page, because Fandom directs all pages on that closed wiki to that special page (since wikis still exist in other languages).


Move previous API classes to the compatibility package

There's a new API in town.
While all previous API implementations can still be used, they belong in the compatibility package and not core.
This includes the config classes, fields, the main Kirki class etc.
The new packages should be self-contained and the compatibility package takes care of themes that will continue using the plugin instead of migrating to the newer packages implementation via composer.

This is done.


Website (react-redux.js.org) is not available...

Website (react-redux.js.org) is not available in Iran!

Our sites are hosted on Netlify. I can only assume that there may be some country-level blocks in place?  Sorry :(


Remove s option from conda clean

The 's' option in conda clean is no longer available. This is causing the generation of notebooks to fail (see recent actions).
https://docs.conda.io/projects/conda/en/latest/commands/clean.html

@larsoner @agramfort can someone please review and merge if happy


Preparation of meeting and guide for concept of a stand for empirical testing of composite structures

The following actions are to do, in order to prepare the meeting and the guide:

[x] #1068

[x] #1069

[x] #1070

All done.


Build backend version

npm run babel compiles source to ES5. Tentatively published to npm @phparkle/js-data-http-backend

Cool! I'll look at this tomorrow.

It's fine if js-data 2.x users want to use @phparkle/js-data-http-backend on Node.js.
For js-data 3.x, I've setup a Node.js build of js-data-http which can be installed from NPM as js-data-http-node, and is currently at version 3.0.0-alpha.5


Streaming from vanilla DataFrames is broken

https://github.com/JuliaDB/SQLite.jl/commit/adfc7d54cd17e77202ac096b89e45d1abd9dfa94 and https://github.com/JuliaData/DataStreams.jl/commit/f507c7e31cf6272bbfcf92cbdcf1dd7cd54250dc changed a lot of things in the API, but also broke streaming from DataFrames with DataArray columns.
On master, if we stream to a DataFrame we get a DataFrame with NullableArray columns:
 using DataFrames, DataStreams, NullableArrays, SQLite
# Make an in-memory database and a table with some values
db = SQLite.DB()
SQLite.query(db, "Create table temp (num INT, str TEXT)")
SQLite.query(db, "insert into temp VALUES (1, 'a')")
SQLite.query(db, "insert into temp VALUES (2, 'b')")
# Pull these back down
source = SQLite.Source(db, "select * from temp")
df = Data.stream!(source, DataFrame)

2×2 DataFrames.DataFrame
│ Row │ num         │ str           │
├─────┼─────────────┼───────────────┤
│ 1   │ Nullable(1) │ Nullable("a") │
│ 2   │ Nullable(2) │ Nullable("b") │

We can also stream this type of DataFrame back into the table:
sink = SQLite.Sink(db, df, "temp")
Data.stream!(df, sink)

SQLite.Sink(Data.Schema:
rows: 2	cols: 2
Columns:
 "num"  Int64
 "str"  UTF8String,SQLite.DB(in-memory),"temp",SQLite.Stmt(SQLite.DB(in-memory),Ptr{Void} @0x0000000035ae41b8))

However, suppose we wanted to add a few more rows.  If we construct a DataFrame using the normal constructors and try to stream it in:
df = DataFrame(num=Int64[5,6], str=UTF8String["g", "f"])
sink = SQLite.Sink(db, df, "temp")
Data.stream!(df, sink)

LoadError: MethodError: `getbind!` has no method matching getbind!(::DataArrays.DataArray{Int64,1}, ::Int64, ::Int64, ::SQLite.Stmt)
Closest candidates are:
  getbind!{T}(!Matched::NullableArrays.NullableArray{T,1}, ::Any, ::Any, ::Any)
  getbind!{T}(!Matched::Array{T,1}, ::Any, ::Any, ::Any)
  getbind!{T}(::Any, !Matched::Type{T}, ::Any, ::Any, !Matched::Any, !Matched::Any)
while loading In[9], in expression starting on line 3

 in anonymous at C:\Users\amellnik\.julia\v0.4\SQLite\src\Sink.jl:60
 in transaction at C:\Users\amellnik\.julia\v0.4\SQLite\src\SQLite.jl:220
 in stream! at C:\Users\amellnik\.julia\v0.4\SQLite\src\Sink.jl:56

Right now the only workaround that I know of is to convert all vanilla DataFrames to NullableArrays DataFrames before streaming them in, as described in my comment here: https://github.com/JuliaStats/DataFrames.jl/issues/933.
I'm still trying to get caught up on all these changes, and will see if I can create a PR that allows either type of DataFrame to be used.
I think this will pose a problem for users unfamiliar with this package, as it's not explicitly mentioned anywhere.  A set of minimal examples of streaming data DataFrame <--> SQLite might also be a good idea for the readme.md, as the examples shown in the tests are somewhat cryptic (and implicitly use NullableArrays constructors for DataFrames).

Thanks for bringing this up; definitely important to support DataArray-based DataFrames for the time being. This is fixed on master (and will very soon be tagged in a new release).


A question in filtering out the detections for evaluation

Hi dear author,
thank you for sharing the codes!
I have a question regarding the filtering process of raw detections from the detector.
Specifically, what does it mean of this line? j should be the index of detected instances in that image, which has nothing to do with the number of class, what does the comment of this line mean by saying #winning class must be class j for this detection to be considered valid?
Best regards,
jianxiang.

j is actually a class index, and results[j] gives us an array of the detections for that specific class.
The 'result' variable is a list of length N, where N = #number of training classes. Each element in the list is an array with the detections belonging to a specific class. Each row in the array is a single detection, of format [bounding box, class_score, logit_distribution].
The typical detection pipeline creates a class detection as long as the class score is above a certain threshold (e.g. 0.2). For example, if there's a bounding box where class 'dog' has score 0.6 and class 'cat' has score 0.3, then this detection will appear twice in 'result' --> once in the 'dog' array of detections, and another time in the 'cat' array of detections. In our paper, we only want to create a detection for the class that had the greatest score (as it can't be both a cat and a dog).
Hopefully that makes sense. You can print the result variable on line 167 if you want to see the setup of the class list of detections.
Otherwise, let me know if there's anything else you want to ask or I'll close this issue tomorrow.

Thanks for the timely and detailed reply. The format you described should come from this (function)[https://rmc-github.robotic.dlr.de/feng-ji/flowDet_i/blob/1efdc82832f129d1a71c1f16785554e841501534/mmdetection/mmdet/core/bbox/transforms.py#L99], right?

The typical detection pipeline creates a class detection as long as the class score is above a certain threshold (e.g. 0.2). For example, if there's a bounding box where class 'dog' has score 0.6 and class 'cat' has score 0.3, then this detection will appear twice in 'result' --> once in the 'dog' array of detections, and another time in the 'cat' array of detections. In our paper, we only want to create a detection for the class that had the greatest score (as it can't be both a cat and a dog).

regrading this example, I have another concern. Since the bbox prediction is class-dependent. So there won't be an exactly same bbox with dog of 0.6 and cat of 0.3. Intuitively, because they are not exactly the same (maybe with a high IoU), it could be the case that a dog overlaps with a small cat, which makes sense and would not require to just take the one with highest score. Then the way you described will exclude these cases.

Yes, the format comes from the function you've linked -- although note that we have altered the multiclass_nms function so that we also return the logit distribution (not standard from mmdet).
Yes, the bounding boxes are class-dependent and won't be exactly the same. You're right that there is a potential that one proposal is capturing 2 different objects -- and thus by only allowing 1 detection per proposal, some objects may be missed. However, this is likely to be a very small number of cases and could only happen when two objects are highly overlapping. Faster R-CNN also returns 1000 object proposals, so we assume that there will be a proposal that better captures each object (e.g. proposal for the cat and another proposal for the small cat), and hopefully each proposal will get the correct corresponding classification and prevent this from happening.
Object detectors are developed for best performance with mAP metric, which rewards high recall as possible, even if this means sacrificing precision. In practice, this often means that there are many, many FP's (not suitable for robotics case). In our paper, we opt for this approach because it removes a large number of FP's, with only minimal FN's introduced.


Evaluate whether to add method to edit royaltyRecipient

Should an author be able to change the royalty recipient of an NFT?

Blocked until we finalize the ERC2981 implementation.


TouchableWithoutFeedback does not work well with Text children.

i've this warning: Warning: TouchableWithoutFeedback does not work well with Text children. Wrap children in a View instead. See RadioButtons
with that code
         `<RadioButtons
            options={ this.state.options }
            onSelection={(selectedOption, selectedIndex) => {console.log(selectedOption)}  }
            renderOption={ (option, selected, onSelect, index) =>{
              return (

               <TouchableWithoutFeedback onPress={onSelect} key={index}>

                   <Text >{option}</Text>

               </TouchableWithoutFeedback>
             );
            }}
            renderContainer={(optionNodes) =>{return <View>{optionNodes}</View> } }

          />`

how i can solve?

You need to put the Text inside a View

I replace use TouchableOpacity.
It's work well

@Jakevin TouchableOpacity will work but it may damage UI, best solution is as @BrunoVillanova  said.

THIS WORKS https://github.com/facebook/react-native/issues/10180#issuecomment-298375648


Relics by Tin Star Games

Changes / Comments
This is the official Tin Star Games character sheet for the Roll20 implementation of Relics: A Game of Angels
Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[ ] Does the pull request title have the sheet name(s)? Include each sheet name.
[ ] Is this a bug fix?
[ ] Does this add functional enhancements (new features or extending existing features) ?
[ ] Does this add or change functional aesthetics (such as layout or color scheme) ?
[ ] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.

Character Sheet Info Roll20 Internal Use only.


Custom-toggle broken on Safari

When using the custom-toggle class in Safari, the toggle knob animates out of bounds.

Expected Behavior
The toggle knob animates left (off) to right (on).
Current Behavior
On Safari the knob animates left out of the bounds of the control.
Possible Solution
This problem is in the difference in parsing left in the following snippet:
.custom-toggle .custom-control-input:checked + .custom-control-indicator:after {
  left: calc(100% - 3px);
  -webkit-transform: translateX(-100%);
          transform: translateX(-100%);
}

Using  left: 95%; is a dirty way fix approximating the 3px margin, and seems to work in all browsers.
Steps to Reproduce

Use Safari.
Click toggle.

Context (Environment)
Tested on both Safari 10.0.2 (webkit 126<IP_ADDRESS>.3), and Safari Technology Preview 11.1 (release 44, webkit 126<IP_ADDRESS>). Ran on on MacOS Sierra 10.12.6.

This is great, thanks for your detailed submission! 😄 I'm on it!


Cannot run the help command

Thanks for creating this great project!
I tried to start the editor as stated by the doc using the following commands but it gives me an error message. I tried to put the license file at /root/.local/share/unity3d/Unity/Unity_lic.ulf but still no luck.
Commands:
docker run -it --rm unityci/editor:2019.2.12f1-android-0 bash
unity-editor help

Error Message:
[1108/204733:ERROR:browser_main_loop.cc(161)] Running without the SUID sandbox! See https://code.google.com/p/chromium/wiki/LinuxSUIDSandboxDevelopment for more information on developing with the sandbox on.
[1108/204733:ERROR:sandbox_linux.cc(308)] InitializeSandbox() called with multiple threads in process gpu-process

I am not sure if this is a bug or just I don't know how to use it. Any help is appreciated! Thanks.

The help command may not work, but other commands do. As the focus of this project is primarily to support CI pipelines, and we offer wide range of documentation on how to set that up, priority for fixing the help command is not very high.
Please do feel free to add more comments if you have any clues.

It is because I tried to run unity-editor and it also give me this error message, so I just thought it just not gonna work.

Multiple successful setups with Android builds have already been reported on our discord channel, these new images are working for the most part. Just not the help command. And I believe without any arguments the CLI has never worked.
By the way Unity-Builder also successfully implements the new images in v2, so you could possibly save yourself a lot of time, by not implementing all of that yourself.
Cheers!

Thanks for your help and this great project again!
Let me try again with arguments!


About FlowNet3D in the paper

Hi, thanks for your great work!
I have a question about FlowNet3D used in your paper. FlowNet3D estimates the motion of 3D point cloud, which is generated by object motion and **sensor motion**,  so why you can identify dynamic objects by a threshold? As you described in the paper:"We set a threshold on the estimated translation of each point to decide the label for each point, i.e., points with translations larger than the threshold are labeled as moving".
In my opinion, large translation of sence flow doesn't mean dynamic objects, maybe just the lidar sensor is moving.  Do you firstly transform the two frames to the same coordinate, and then estimate the sence flow?

Thanks for your interest and question.
Yes, the correct way is to first estimate the ego-motion of our car using odometry/SLAM and then check the absolute translation after compensating the ego-motion, as described in the related sceneflow papers. Since we focus more on LiDAR-MOS and have a limited page size, we can not give more details.


New hook to be called before challenge validation

After adding/removing resource records on ClouDNS (and probably other authoritative DNS providers, I guess) you have to wait while the new zone is propagated across all of their servers. This is a time-consuming process and it isn't really predictable, luckily ClouDNS offers a way to check if the zone is updated.
Now that deploy_challenge is done for all -d domains at once it would be great to have a hook that is called after all deploy_challenges but before these challenges are validated. That way we can make deploy_challenge add all TXT records asynchronously and call just one loop in before_challenge_validation to wait while the zone isn't updated across all ClouDNS servers.

You could achieve this by using HOOK_CHAIN="yes" and then simply having your hook wait and test after deploying the challenges before returning from the hook.

I know that but I think it makes sense to have a hook where you can check the challenges yourself before telling the CA to do it, even when HOOK_CHAIN="yes" is set.

It is the responsibility of the deploy_challenge hook to ensure that the challenge is successfully deployed and ready for validation. This includes verifying that it has propagated to all authoritative nameservers. Whether that involves HOOK_CHAIN or not.
If you need to verify that the challenge has been deployed successfully, that should be done before the hook returns.


Theme: hyper-seti-monokai

Hyper Seti-Monokai – Dark theme based on the Atom theme by schmittyjd/monokai-seti

@adamellsworth pls submit a pull-request


Telemetry System

In order for engineering and product to better understand the usage of the product we need to build telemetry in Chef Infra Server to provide usage data via our existing telemetry flow (see Automate / Workstation)
Data to Collect

System configuration data

CPU
Disk
Memory
Cloud

Configuration

Add-ons
HA
External PG/ES

Product usage

Node count
User count
Policyfiles
OS breakdown in nodes
Chef client breakdown in nodes

Details

Opt-out via new server attribute
If Automate reporting is configured we will communicate with automate to gather the install ID and use that during reporting

Moved to JIRA


project: add --verbose flag

E.g. snapp project foo --verbose
For insight into why npm install might be hanging. We don't show it all the time b/c it clutters up the UX and makes it harder for the user to see the "done" and "remaining" steps.

Closing to clean up. Can consider reopening if the value becomes apparent here in the future.


Updating services is not hooked up

I was looking into implementing a custom service and noticed the updateStatus method is not implemented. Unless I am otherwise mistaken this means the app doesn't actually do anything (at least at the moment).
See: https://github.com/instatushq/out/blob/main/src/services/service.ts#L12

The base updateStatus should be overridden.
 I have been staring at code all day and am starting to think it's time to take a break.

You're not at all :D
I need a break too lol


User Mapping

Under Ad lookup mapping for step 4 where there is screenshot of the ad attribute mapping. The "AADEmail" should be "mail" could the document be updated as it is bit confusing
https://docs.microsoft.com/en-us/power-bi/service-gateway-enterprise-manage-ssas#ad-lookup-mapping
Thanks

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6fa43934-b1b5-2227-9f9e-cfce1801b659
Version Independent ID: 0d169b19-7c1c-b37d-3915-b8c55da6f0ff
Content: Manage your data source - Analysis Services - Power BI
Content Source: powerbi-docs/service-gateway-enterprise-manage-ssas.md
Service: powerbi
GitHub Login: @mgblythe
Microsoft Alias: mblythe

Thanks for your comment, @rajj281. We’ve forwarded your feedback to the writer, who should respond soon. Thanks!

I updated the screenshot to use "Email" which I believe is the correct value for this option. Feel free to reopen if there's a problem with this fix. Thanks!


general: there should be a way to deploy and set network locations of bundle folder and miniconda

implemented in v0.4.0


Reference docs?

Where are the reference docs? What is the type of "authClient" in the example in the README? How can you use it by itself?

As it would turn out, this is annoyingly hard with TypeScript.  I tried a few methods:

Using esdoc, with the TypeScript plugin.  - This was really just a glorified jsdoc comment parser.  The TypeScript doesn't appear to actually read types from the TypeScript code, and produces low quality typing information.
Using TypeDoc. - TypeDoc doesn't appear to be maintained very well, and crashes with TypeScript 2.6.  I was able to hack up a fix, but it doesn't appear as though they're handling pull requests in a timely manner.

Right now, TypeDoc seems like the best bet.  I have the preview docs published here:
https://auth-library.firebaseapp.com/
The docs are showing each class as a global entity, which is wrong.  I need to figure out how to bend TypeDoc to use a module entry point (index) as the jumping point.  I'll keep banging on this until it's reasonably good.
In the interim - we've really expanded the examples section in the next branch.

Another alternative here is to just add duplicate jsdoc annotations to the TypeScript classes and properties, purely for the purposes of generating decent documentation.  Thoughts @ofrobots?

Code that is not never tested/compiled by a compiler is worse than no code at all. IMO jsdoc type annotations fall into this category and would be fast out of date and worse than no docs.
deeplearn.js seems to have some pretty reasonable docs generated using typedoc: https://deeplearnjs.org/docs/api/globals.html. Perhaps we can follow their setup?


Cleanup db/seeds.rb

It looks like users were referenced by strings previously. I updated the script to use the superadmin.
Posts were previously created with different users but I just used the same one.
To preserve the different users this would need to create those users as well. It doesn't currently do this.

Thanks for this, Jim! Pulling it in right now.


Update Globals “nav”

Automatically generated by Netlify CMS

👷 Deploy Preview for greeking processing.

Name
Link

🔨 Latest commit
a3005acab8b07e8e31e33ab99cac00d23fbb9492

🔍 Latest deploy log
https://app.netlify.com/sites/greeking/deploys/626fe0df3035f50008c80034


Pixhawk 4 Mini (fmu-v5) minor issues

Autopilot: Pixhawk 4 Mini (fmu-v5)
PX4 Version: Today's Master (100f9553cef2203c818ab98e13d39406c6fc3c8c)
Minor issues while setting up board for flight:

By default the  param was set although the board doesn't have an IO. The firmware doesn't ignore this param therefore I don't have my pwms on the fmu port. When I ran the 'pwm info' command I got a hardfault.
During boot up the buzzer inside the Pixhawk 4 GPS makes a strange sound instead of the regular sound from the normal pixhawk 4.
PWR LED (green) is blinking and ACT LED (blue) is off during normal operation. Should the PWR LED always be on and the ACT LED blink? This changed on master in the last couple of weeks. Before PWR was always on and ACT always off.

FYI @davids5 @bkueng

FYI @jamming

@DanielePettenuzzo
I do not have the final rev of this FMU. (@jinger26 any eta?) So I do not have labeling on the LEDs. I can tell you from what my FULL FMUv5 we are indeed blinking the pwr LED (see below). But on the REV of the FMUv5 mini I have, with the PWM connectors pointing up, USB to the right, the LED's are G R B. However the R and G LED are swapped (are on different pins)  to fmuv5. So my red led is blinking.
FYI @jamming, @jinger26 To be clear This is either an assembly issue or lay out bug on the version and as built mini I have.
led_on(LED_RED) is turning on GREEN
led_on(LED_GREEN) is turning on RED

Once all the HW is correct we need to fix the logical use of the LEDs.
The Labeling is

Label
Color
Bootloader usage
FMU usage

ACT - Activity
Blue
Flutters when the bootloader is receiving data
Indication of ARM

B/E - In Bootloader / Error
Red/Amber
Flutters when in the bootloader
Indication of an ERROR

PWR - Power
Green
not used by booloader
indication of ARM state

Red/Amber
Blue
Green
** Meaning **

10Hz
x
x
Overload CPU load > 80% or RAM usage > 98%

OFF
x
x
Overload CPU load <= 80% or RAM usage <= 98%

NA
OFF
4 Hz
actuator_armed->armed && failsafe

NA
ON
4 Hz
actuator_armed->armed && !failsafe

NA
OFF
1 Hz
!actuator_armed->armed && actuator_armed->ready_to_arm

NA
OFF
10 Hz
!actuator_armed->armed  && !actuator_armed->ready_to_arm

x - is any state
The source of status LED control (and color choice) is in Commander. There is no abstraction, this will need to be remedied. The Boards should provide a set of defines or const array for translation by indication OVERLOAD_LED, ARMED_LED, to the color then the code can "activate" the indication on the OVERLOAD_LED and that can be whatever LED the board chooses. The latter cost more FLASH bit is more appealing to me..
As secondary issue, I discussed with @dagar the interface to the LEDs are a RW-IOCTL interface. While this is a proper user/kernel separation and an abstraction. There is a lot code to enact it.
perhaps we should consider a re-factor
#define SET_OVERLOAD_LED(on_off)
#define TOGGLE_OVERLOAD_LED()

or
board_set_status_led(int logical_led_function, int state {on off, toggle})

The macros could be a direct GPIO manipulation on a platform that supports it, or an IOCTL on one the does not.
The call able could be a translation and then a direct GPIO manipulation on a platform that supports it, or a translation and IOCTL on one the does not.
Thoughts?

On the final rev of FMUv5 mini and FMUv5 pro, the definition of LED are the same.
Green      --- PC6 --- PWR
Amber   --- PB1 --- B/E
Blue        --- PC7 --- ACT
------------------ Original ------------------
From:  "David<EMAIL_ADDRESS>Date:  Fri, Aug 17, 2018 00:35 AM
To<EMAIL_ADDRESS>Cc<EMAIL_ADDRESS><EMAIL_ADDRESS>Subject:  Re: [PX4/Firmware] Pixhawk 4 Mini (fmu-v5) minor issues (#10034)
@DanielePettenuzzo
I do not have the final rev of this FMU. (@jinger26 any eta?) So I do not have labeling on the LEDs. I can tell you from what my FULL FMUv5 we are indeed blinking the pwr LED (see below). But on the REV of the FMUv5 mini I have, with the PWM connectors pointing up, USB to the right, the LED's are G R B. However the R and G LED are swapped (are on different pins)  to fmuv5. So my red led is blinking.
FYI @jamming, @jinger26 To be clear This is either an assembly issue or lay out bug on the version and as built mini I have.
led_on(LED_RED) is turning on GREEN led_on(LED_GREEN) is turning on RED
Once all the HW is correct we need to fix the logical use of the LEDs.
The Labeling is
Label Color Bootloader usage FMU usage
ACT - Activity Blue Flutters when the bootloader is receiving data Indication of ARM
B/E - In Bootloader / Error Red/Amber Flutters when in the bootloader Indication of an ERROR
PWR - Power Green not used by booloader indication of ARM state
Red/Amber Blue Green ** Meaning **
10Hz x x Overload CPU load > 80% or RAM usage > 98%
OFF x x Overload CPU load <= 80% or RAM usage <= 98%
NA OFF 4 Hz actuator_armed->armed && failsafe
NA ON 4 Hz actuator_armed->armed && !failsafe
NA OFF 1 Hz !actuator_armed->armed && actuator_armed->ready_to_arm
NA OFF 10 Hz !actuator_armed->armed  && !actuator_armed->ready_to_arm
x - is any state
The source of status LED control (and color choice) is in Commander. There is no abstraction, this will need to be remedied. The Boards should provide a set of defines or const array for translation by indication OVERLOAD_LED, ARMED_LED, to the color then the code can "activate" the indication on the OVERLOAD_LED and that can be whatever LED the board chooses. The latter cost more FLASH bit is more appealing to me..
As secondary issue, I discussed with @dagar the interface to the LEDs are a RW-IOCTL interface. While this is a proper user/kernel separation and an abstraction. There is a lot code to enact it.
perhaps we should consider a re-factor
#define SET_OVERLOAD_LED(on_off)  #define TOGGLE_OVERLOAD_LED()
or
board_set_status_led(int logical_led_function, int state {on off, toggle})
The macros could be a direct GPIO manipulation on a platform that supports it, or an IOCTL on one the does not.
The call able could be a translation and then a direct GPIO manipulation on a platform that supports it, or a translation and IOCTL on one the does not.
Thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@DanielePettenuzzo - see LEDs are fixed here https://github.com/PX4/Firmware/pull/10579
PWR is on solid and ACT indicates the arm state.

@DanielePettenuzzo the SYS_USE_IO is here https://github.com/PX4/Firmware/pull/10580

@DanielePettenuzzo / @PX4/testflights - do you have FMUv5mini RC05?
Please cross test that
Leds is fixed
SYS IO set ok.

During boot up the buzzer inside the Pixhawk 4 GPS makes a strange sound instead of the regular sound from the normal pixhawk 4.

This should have been fixed in master when the tone_alarm/tune control came in.
(rebase the PRs into one to test)

Bug fix fmu hard fault on pwm info was in b578419e0950994b4e0a002362e294b3fc74fca6

@davids5 yes I have the RC05. I can test these.

Are we able to close this issue now? @davids5 @dagar

@jinger26 the PR listed above are merged. So I will close this. What is left is the back port.

@hamishwillee do we need to document the LED labelings above?

In FMUv5 I have formally defined UI LED and Status LEDs as an explanation of the Legacy LEDs that were on FMUv2 and FMUv4 HW.
The Super Bright RGB LED is the UI LED. (The normal LED) The discrete LEDs (or not so bright RGB LED on FMUv4)  are the status LED's as marked on the HB FMUv5 (pixhawk 4) case these are the status LED for the PX4IO and FMU SoC and indicate Power, bootloader mode and activity and Errors.
Green      --- PC6 --- PWR
Amber   --- PB1 --- B/E
Blue        --- PC7 --- ACT
See the Status LED and UI LED definition it the pinining:
https://docs.google.com/spreadsheets/d/1-n0__BYDedQrc_2NHqBenG1DNepAgnHpSGglke-QQwY/edit#gid=912976165

@hamishwillee - miss-typed your name above. Please see https://github.com/PX4/Firmware/issues/10034#issuecomment-440787304


Create notify_slack.yml

Notify team on slack for push or pull request to any branch on code extension. Pull request messages are null. Functionality is confirmed through slack so no unit tests necessary.

[ x] Does the PR description accurately reflect the changes made?
[ x] Do the commit messages accurately reflect the changes made?
[ x] Is the changelist for this pull request under ~200 lines? (Excepting automatically generated code and package installations)
[ x] Does the code follow the coding style guidelines that we have set up?
[ ] Does the coder include unit tests for his functions?
[ ] Does the QA who reviews the code include his unit tests for all the functions?
[ x] Is there a documentation in place if the functions is related to how users build, test, interact with, or release code?

:tada: This PR is included in version 1.0.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


testnet 3.3 ☠  Coda Daemon crashed. genesis_ledger_accounts download error.

command

coda daemon -peer $SEED1

version

~# coda version
Commit fdc283b on branch master

error log

	error: "(monitor.ml.Error\n (\"Process.run failed\"\n  ((prog curl)\n   (args\n    (--fail -o\n     /tmp/s3_cache_dir/genesis_ledger_accounts_e7fd308899bca6956b093b635988ea06630adbf540e13d38dcd2f7ab629da53c_f094d0eb814dbbff2f41f3f69c414331566f2c4a884c309944899ea59f101b9a.tar.gz\n     https://s3-us-west-2.amazonaws.com/snark-keys.o1test.net/genesis_ledger_accounts_e7fd308899bca6956b093b635988ea06630adbf540e13d38dcd2f7ab629da53c_f094d0eb814dbbff2f41f3f69c414331566f2c4a884c309944899ea59f101b9a.tar.gz))\n   (exit_status (Exit_non_zero 22)) (stdout \"\")\n   (stderr\n    (\"  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current\"\n     \"                                 Dload  Upload   Total   Spent    Left  Speed\"\n     \"\\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\\r  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0\"\n     \"curl: (22) The requested URL returned error: 404 Not Found\" \"\"))))\n (\"Raised at file \\\"src/error.ml\\\" (inlined), line 9, characters 14-30\"\n  \"Called from file \\\"src/or_error.ml\\\", line 72, characters 17-32\"\n  \"Called from file \\\"src/deferred1.ml\\\", line 17, characters 40-45\"\n  \"Called from file \\\"src/job_queue.ml\\\" (inlined), line 131, characters 2-5\"\n  \"Called from file \\\"src/job_queue.ml\\\", line 171, characters 6-47\"))"

crash report
coda_crash_report_2020-09-17_11-04-01.607135.tar.gz

this error is not related to the crash. the actual crash is a dupe of #6001


is it better than orginal version? 比原本优化了哪些地方？

the orginal version last update time is 1 Jul 2009，more than ten years. is it better than orginal version?
比原本优化了哪些地方？

Have you taken a look at the commit log?  I don't remember off the top of my head what's different between this and the original, but I feel comfortable at least saying that this version "works and isn't worse."


Scully starters section update

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] The commit message follows our guidelines: https://github.com/scullyio/scully/blob/main/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[X] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[X] Other... Please describe: Updates information about Flotiq Scully starters

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[X] No

Other information

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


chore(deps): update terraform module dcos-terraform/dcos/aws to v0.2.13

This PR contains the following updates:

Package
Type
Update
Change

dcos-terraform/dcos/aws (source)
terraform
patch
0.2.12 -> 0.2.13

Release Notes

dcos-terraform/terraform-aws-dcos
v0.2.13
Compare Source

Renovate configuration
:date: Schedule: At any time (no schedule defined).
:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.
:recycle: Rebasing: Whenever PR becomes conflicted, or if you modify the PR title to begin with "rebase!".
:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

Available now for Enterprise: Renovate Pro with real-time webhook handling and priority job queue.

:tada: This PR is included in version 5.0.36 :tada:
The release is available on:

v5.0.36
GitHub release

Your semantic-release bot :package::rocket:


NextjsSite Construct does not forward VPC configuration to the Image Optimization Function lambda

Lower environments of my application talk to internal-only DNS/resources. For this reason, I have configured my NextjsSite SST construct to attach my application to my VPC like so:
const vpc = Vpc.fromLookup(stack, 'VPC', { vpcId: '<MY ID>' });

const site = new NextjsSite(stack, name, {
  cdk: {
    server: { vpc },
  },
  //...
});

This works properly for my application code. It is able to talk to services behind private-network DNS. However, my app also loads images from private DNS. As far as I can tell, the application is unable to reach these images. According to the open next documentation, Next.js is routing images loaded via the Image component through the Image Optimization Function (see below)

This function can't seem to access images only available via the VPC (requests time out, DNS not resolvable). This implies that the VPC configuration is only given to the Server Function app lambda, and not forwarded to the Image Processing Function lambda.
AlcaponeYou in discord confirmed this to be the case, that vpc props are not forwarded to that lambda: /packages/sst/src/constructs/NextjsSite.ts

See original thread in Discord: https://discord.com/channels/983865673656705025/1187522846939959377

Thanks! Would appreciate a PR!

Any solutions?

We are transition this repo to https://github.com/sst/v2 and are closing this issue for now. If it is still relevant please reopen it there - sorry for the trouble


log into pocket button not working

When I try to save an article to pocket I am taken to a login screen (in Vienna, not the browser). So far so good. I enter my credentials, just checked to work in the browser. The log in button doesn't do anything. It looks de-activated, as if I didn't type password or login. The pointer doesn't change from an arrow to a hand when I am hovering over the button. I tried to log out and back in in the browser (firefox) and sure enough it all works.

Do you have Javascript enabled in Vienna's internal browser ? (Advanced preferences)

That was it. Thanks


Diagnostics settings screenshot should be updated

Team,
I think Diagnostics settings screenshot should be updated.
There's one more item added called 'FrontDoor Health Probe Log'.
Best,
Youkhang.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: de4370d8-9497-7fc4-1fd0-8c88b810959e
Version Independent ID: 6f32101e-de15-a63b-f5cb-893e37ac407f
Content: Azure Web Application Firewall monitoring and logging
Content Source: articles/web-application-firewall/afds/waf-front-door-monitor.md
Service: web-application-firewall
GitHub Login: @vhorne
Microsoft Alias: victorh

@youkhi , thank you for your feedback. We have assigned this to the content owner/author for for updating the doc accordingly.
@vhorne , could you please update the diagnostic settings screenshot as another log has been added to Azure Front Door which is 'FrontDoor Health Probe Log'?

Screenshot updated
#please-close


in_tail, use path in output

Hi,
I'm trying to do something really simple but fail to do it so I'm asking here (maybe not the best place).
Basically I want to tail the container logs of my kubernetes nodes and send them to splunk.
To do so I' want to use the in_tail plugin and one of the splunk HEC output plugin, the configuration would look like this (this is not working cause ${record["path"]} does not exists):
<source>
  @type tail
  path /var/log/containers/*.log
  pos_file /tmp/fluentd-containers.pos
  tag kubernetes.containers
  refresh_interval 5s
  log_level debug

  time_key time
  time_format %Y-%m-%dT%H:%M:%S.%NZ
  format json
  read_from_head true
</source>

<match kubernetes.containers>
  type splunk-http-eventcollector
  server <IP_ADDRESS>:9990
  verify false
  token aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaaaaaaaaaa

  # Convert fluent tags to Splunk sources.
  # If you set an index, "check_index false" is required.
  host fluentd
  index kubernetes-containers
  #check_index false
  source ${record["path"]}
  sourcetype _json

  # TIMESTAMP: key1="value1" key2="value2" ...
  #time_format unixtime
  #format kvp

  # Memory buffer with a short flush internal.
  buffer_type memory
  buffer_queue_limit 16
  buffer_chunk_limit 8m
  flush_interval 10s
</match>

My problem lies with the source option of splunk output plugin, I would like it to be set to the value of the tailed file.
Could you tell me how I can do that ?
Regards.

Any idea ?

Need to use v0.14 and v0.14 new plugin API in output code.
https://docs.fluentd.org/v0.14/articles/api-plugin-output#understanding-chunking-and-metadata
BTW, don't use github issue for question. Please follow this guide
https://github.com/fluent/fluentd/blob/master/CONTRIBUTING.md#got-a-question-or-problem


Calorie count when "calorie/protein count up" is enabled

Hi, I wanted to ask if it was possible to have the app take into account excercise for the total calorie count when the option for "count up" is enabled.
I noticed when this option is disabled and you add excercise calories it subtracts from the total remaining for the day, but when the option is enabled the value stays at only calories consumed.
A simple solution would be to subtract from the current spent or to simply increase the total amount, i.e:
Calories 800/1800
If I add excercise of say, 400 kcal: it should show Calories 400/1800 or Calories 800/2200
Cheers!

Let me look at this, but it seems reasonable!

Deployed - let me know what you think!

Works perfectly! Adding to total count instead of subtracting from current was the best choice to avoid confusion.
Thanks a bunch!


exclude sensitive information from your repository

.env often includes sensitive information like database credentials and API keys, it is a best practice to exclude this information from your repository

Hey,
I little bit reverted that stuff again. Because you should use like an .env.prod for prod. or an .env.local these are not committed then.
See like: https://symfony.com/doc/current/configuration.html#configuring-environment-variables-in-env-files

My Pull Request is for situation, if you create you for first time project like  composer create-project frosh/shopware:dev-main myProject. An .env file WILL be created there, which already contains login information to database. That's fine. But I don't want to check in this file in my custom project.

That repo is deprecated. Use composer create-project shopware/production:dev-flex myProject

That is absolutely right 🙈 Should be composer create-project shopware/production:dev-flex myProject. But after I created a project, .env should not goes into my custom project. at least that would be my opinion.

then I guess one of those files should be generated instead of .env

What about generate both,  a .env and a .env.local file? The .env file will only contain some default data like
APP_ENV=dev
APP_URL=http://localhost

and can be commited to the repository while the .env.local will hold all the sensitive data like the current .env.

You can create only one file.
https://github.com/symfony/flex/blob/1.x/src/Configurator/EnvConfigurator.php#L207