Deploying Prisma with AWS Lambda and Webpack

Bug description
I want to start off by saying I am absolutely in love with the prisma platform, and everything it provides, and I can't state enough how much I appreciate the efforts of the entire team. Thank you.
I have spent the better part of a weekend trying in earnest to deploy a simple rest api using prisma2, unsuccessfully for one reason or another. While I am deploying and building on windows (which is obviously an issue with the binary), I have also tried to build and deploy from wsl, as well as github actions (both debian base, while lambda is centos based). I have tried every webpack configuration I could think of, including every possible binary I can scrounge up (for instance, manually copying query-engine-rhel-openssl-1.0.x into the directory), all with zero luck. I have tried outputting prisma client to a directory that is not node_modules, copying that, referencing it, all with no changes. My initial thinking was that because I am building on windows it was causing issues, and while it was causing an issue, not using windows did not solve my problems.
I know there are a handful of issues that address this in bits and pieces, some old, some really old, some about Windows, some about chmod, some about serverless, some about photon, I have been through all of them with no success.
The majority of the time my error is simply:
Query engine binary for current platform "rhel-openssl-1.0.x" could not be found.
This probably happens, because you built Prisma Client on a different platform.
(Prisma Client looked in "/query-engine-rhel-openssl-1.0.x")

Files in /:

  bin
  boot
  dev
  etc
  home
  lib
  lib64
  media
  mnt
  opt
  proc
  root
  run
  sbin
  srv
  sys
  tmp
  usr
  var

You already added the platforms "native", "rhel-openssl-1.0.x" to the "generator" block
in the "schema.prisma" file as described in https://pris.ly/d/client-generator,
but something went wrong. That's suboptimal.

Needless to say, it's been suboptimal. Before I continue down my journey into madness, my question is simply: is this a valid usecase? Is it possible to have prisma deployed to aws lambda (ideally using the serverless framework)?
How to reproduce

Build a simple serverless app
Add a simple prisma schema
Deploy to aws lambda
Attempt to query the database

Expected behavior
Query completes successfully
Prisma information
"@prisma/client": "^2.0.0-beta.3",
"@prisma/cli": "^2.0.0-beta.3",

Environment & setup

OS: Windows, WSL, and Ubuntu-latest via github actions

Database: PostgreSQL

Prisma version: @prisma/cli          : 2.0.0-beta.3
Current platform     : windows
Query Engine         : query-engine 2fb8f444d9cdf7c0beee7b041194b42d7a9ce1e6
Migration Engine     : migration-engine-cli 2fb8f444d9cdf7c0beee7b041194b42d7a9ce1e6
Introspection Engine : introspection-core 2fb8f444d9cdf7c0beee7b041194b42d7a9ce1e6

Node.js version: v12.16.2

As is typical, all roads lead back to webpack!
I was finally able to get this working, although not exactly on windows (see below). The main issue was serverless webpack running another yarn install prior to packaging, which was not running my prisma generate properly. This caused my @prisma/client to be either empty, or at least not include the required binaries. Moral of the story, you cannot simply let webpack package @prisma/client as it will roll in all the js, but not keep any binaries around.
Here is my final setup:
Serverless.aml
plugins:
  - serverless-webpack

provider:
  name: aws

custom:
  webpack:
    webpackConfig: 'webpack.config.js'
    includeModules: true # This is required
    packager: 'yarn'
    packagerOptions:
      scripts: # this is the magic
        - prisma generate

webpack.config.js (standard serverless webpack stuff excluded)
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = {
  externals: [nodeExternals()], // this is required
  plugins: [
    new CopyWebpackPlugin(['./schema.prisma']), // without this the prisma generate above will not work
   ]
};

prisma.schema
generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "rhel-openssl-1.0.x"]
}

With these three things I was able to build and deploy the serverless api from osx while still using serverless-webpack. The real magic is the copy of the schema file, and running the prisma generate script post build.
Unfortunately I cannot deploy from windows currently as when I run primsa generate with the above schema it simply hangs forever. When I remove rhel-oplenssl-1.0x from the binaryTargets it succeeds, but only generates the windows binary. Ideally on windows it would be nice to be able to generate whichever binary is specified, even though it can't be ran.
I hope this helps someone in the future!
I am going to leave this open for now, at the discretion of the owners, as I still cannot deploy from windows, but the bulk of the issue (deploying prisma2 using serverless, serverless webpack, to aws lambda) has been solved.

You are a hero bruv! 🔥

@dested  Thanks!!  :raised_hands:

I'm getting the following error Error: yarn run script0 failed with code 1 😢

If you put SLS_DEBUG=* into your path itll give you the expanded error, but more than likely its due to prisma not being found. The only way I was able to get around this was making sure prisma cli was installed globally npm install -g @prisma/cli before running the command.

@dested installing @prisma/cli globally worked here! Thanks 😄

@dested Thanks for the great write up. You are using webpack to bundle your application and you need to copy the binaries over. In your case, you are using Prisma generate via webpack to do so, while that would also work, the faster way to do it will be to copy the binaries directly.
This is where we touch on that in the docs https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/module-bundlers
Does that make sense? Please feel free to ask further questions.

@divyenduz, the new title is perfect.
So there are a couple of issues that I ran into along the way that makes simply using webpack copy insufficient, specifically that serverless-webpack runs its own yarn install --production, which by default does not kick off the postinstall script, which was clobbering my @prisma/client folder (causing the "prisma client not generated" error at runtime). The second was the location it searches for the binaries, and frankly access to the binaries themselves. It may have been my fault, but no amount of environment variable pathing for the query engine binary was enough to satisfy prisma. That is why I opted to lean on default behavior as much as possible and simply 1. force serverless webpack to run generate post install, 2. force webpack to not bundle up my @prisma/client using nodeExternals(), and 3. manually copy over my schema file (which tbh im not 100% sure is needed) afterwords.
On the note about simply copying over the binaryTargets for other platforms when on windows, it very strangely just fails silently. Because of this, to deploy I must switch to WSL, which is more annoying than anything. I will post that as a separate issue later today after I try to track down exactly what is failing.
Thanks for your support!

thank you very much @dested 🔥👍

thank you very much @dested 🔥👍
I finally decided to use docker with prisma. But I think copy-webpack-plugin is very good way to use serverless.

I have a one more question. @dested
I am getting this following error below

How can I do ?
This is my webpack.config.js
const slsw = require('serverless-webpack');
const nodeExternals = require('webpack-node-externals');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = {
  entry: slsw.lib.entries,
  target: 'node',
  // Generate sourcemaps for proper error messages
  devtool: 'source-map',
  // Since 'aws-sdk' is not compatible with webpack,
  // we exclude all node dependencies
  externals: [nodeExternals()],
  mode: slsw.lib.webpack.isLocal ? 'development' : 'production',
  optimization: {
    // We do not want to minimize our code.
    minimize: false,
  },
  performance: {
    // Turn off size warnings for entry points
    hints: false,
  },

  plugins: [
    new CopyWebpackPlugin(['./prisma/schema.prisma']), // without this the prisma generate above will not work
  ],
  // Run babel on all .js files and skip those in node_modules
  module: {
    rules: [
      {
        test: /\.js$/,
        loader: 'babel-loader',
        include: __dirname,
        exclude: /node_modules/,
      },
    ],
  },
};

I solved

thank you very much @dested 🔥👍
I finally decided to use docker with prisma. But I think copy-webpack-plugin is very good way to use serverless.

I have a one more question. @dested
I am getting this following error below

How can I do ?
This is my webpack.config.js
const slsw = require('serverless-webpack');
const nodeExternals = require('webpack-node-externals');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = {
  entry: slsw.lib.entries,
  target: 'node',
  // Generate sourcemaps for proper error messages
  devtool: 'source-map',
  // Since 'aws-sdk' is not compatible with webpack,
  // we exclude all node dependencies
  externals: [nodeExternals()],
  mode: slsw.lib.webpack.isLocal ? 'development' : 'production',
  optimization: {
    // We do not want to minimize our code.
    minimize: false,
  },
  performance: {
    // Turn off size warnings for entry points
    hints: false,
  },

  plugins: [
    new CopyWebpackPlugin(['./prisma/schema.prisma']), // without this the prisma generate above will not work
  ],
  // Run babel on all .js files and skip those in node_modules
  module: {
    rules: [
      {
        test: /\.js$/,
        loader: 'babel-loader',
        include: __dirname,
        exclude: /node_modules/,
      },
    ],
  },
};

I solved my issue
plugins: [
    new CopyWebpackPlugin({ patterns: ['./prisma/schema.prisma'] }), // without this the prisma generate above will not work
  ],

@dested Thanks for the great write up. You are using webpack to bundle your application and you need to copy the binaries over. In your case, you are using Prisma generate via webpack to do so, while that would also work, the faster way to do it will be to copy the binaries directly.
This is where we touch on that in the docs https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/module-bundlers
Does that make sense? Please feel free to ask further questions.
P.S. I edited the issue title to reflect its state better, please let me know if you do not agree with it.

  Query engine binary for current platform "darwin" could not be found.
This probably happens, because you built Prisma Client on a different platform.
(Prisma Client looked in "/query-engine-darwin")

Files in /:

Why in the heck is Prisma Client looking at the top path of my freaking 💻 ? 🗯
I am configuring in webpack like this one:
plugins: [
    new CopyWebpackPlugin({
      patterns: [
        {
          from: path.join(
            __dirname,
            "node_modules/@prisma/cli/query-engine-darwin"
          ),

          // 'dist' is just the 'webpack' default
          to: path.join(__dirname, "dist"),
        },
      ],
    }),
  ],

It doesn't matter whether it copies or not because the code from 'dist/main.js' seems to always look 👀 at the top-level absolute path on my 💻 . Why???????? 😱

Does someone have a working boilerplate of this somewhere I could inspect. Im still struggling at bit. Or could maybe spot something I'm doing wrong....
webpack config
`const slsw = require("serverless-webpack");
const nodeExternals = require("webpack-node-externals");
const CopyWebpackPlugin = require("copy-webpack-plugin");
module.exports = {
entry: slsw.lib.entries,
target: "node",
// Generate sourcemaps for proper error messages
devtool: "source-map",
// Since 'aws-sdk' is not compatible with webpack,
// we exclude all node dependencies
externals: [nodeExternals()],
mode: slsw.lib.webpack.isLocal ? "development" : "production",
optimization: {
// We do not want to minimize our code.
minimize: false,
},
performance: {
// Turn off size warnings for entry points
hints: false,
},
plugins: [new CopyWebpackPlugin({ patterns: ["./prisma/schema.prisma"] })],
// Run babel on all .js files and skip those in node_modules
module: {
rules: [
{
test: /.js$/,
loader: "babel-loader",
include: __dirname,
exclude: /node_modules/,
},
],
},
};`
serverless.yml
`service: media-server-api
Use the serverless-webpack plugin to transpile ES6
plugins:

serverless-webpack

custom:
efsAccessPoint: ${env:efs_access_point}
LocalMountPath: ${env:lambda_mount_point}
subnetsId: ${env:lambda_subnet}
securityGroup: ${env:lambda_security_grp}
database_url: ${env:DATABASE_URL}
webpack:
webpackConfig: ./webpack.config.js
includeModules: true
packagerOptions:
scripts: # this is the magic
- prisma generate
serverless-offline:
port: 4000
provider:
name: aws
runtime: nodejs10.x
memorySize: 512
region: ${env:aws_region}
profile: ${env:aws_profile}
timeout: 900
functions:
status:
handler: src/index.handler
environment:
MNT_DIR: ${self:custom.LocalMountPath}
DATABASE_URL: ${self:custom.database_url}
DEBUG: prisma-client
vpc:
securityGroupIds:
- ${self:custom.securityGroup}
subnetIds:
- ${self:custom.subnetsId}
iamManagedPolicies:
- arn:aws:iam::aws:policy/AmazonElasticFileSystemClientReadWriteAccess
events:
- http:
method: GET
path: /
resources:
extensions:
StatusLambdaFunction:
Properties:
FileSystemConfigs:
- Arn: "${self:custom.efsAccessPoint}"
LocalMountPath: "${self:custom.LocalMountPath}"
`
dependencies
  "dependencies": {     "@prisma/client": "2.9.0",     "aws-sdk": "^2.773.0",     "dotenv": "^8.2.0",     "lambda-router": "^2.10.0"   },   "devDependencies": {     "@prisma/cli": "2.9.0",     "serverless": "^2.8.0",     "serverless-dotenv-plugin": "3.0.0",     "babel-core": "^6.26.3",     "babel-loader": "^7.1.4",     "babel-plugin-source-map-support": "^1.0.0",     "babel-plugin-transform-runtime": "^6.23.0",     "babel-preset-env": "^1.7.0",     "babel-preset-stage-3": "^6.24.1",     "copy-webpack-plugin": "^5.1.1",     "serverless-offline": "^3.25.6",     "serverless-webpack": "^5.1.0",     "webpack": "^4.16.2",     "webpack-node-externals": "^1.6.0"   },

@sheldonj Here is a project I did early on in year for you to look at: https://github.com/AmoDinho/prisma2-f1-demo
This is what my Webpack config looks like:

const slsw = require("serverless-webpack");
const nodeExternals = require("webpack-node-externals");
const CopyWebpackPlugin = require("copy-webpack-plugin");

module.exports = {
  entry: slsw.lib.entries,
  target: "node",
  // Generate sourcemaps for proper error messages
  devtool: "source-map",
  // Since 'aws-sdk' is not compatible with webpack,
  // we exclude all node dependencies
  externals: [nodeExternals()],
  mode: slsw.lib.webpack.isLocal ? "development" : "production",
  optimization: {
    // We do not want to minimize our code.
    minimize: false,
  },
  performance: {
    // Turn off size warnings for entry points
    hints: false,
  },

  plugins: [
    new CopyWebpackPlugin(["./prisma/schema.prisma"]), // without this the prisma generate above will not work
  ],
  // Run babel on all .js files and skip those in node_modules
  module: {
    rules: [
      {
        test: /\.js$/,
        loader: "babel-loader",
        include: __dirname,
        exclude: /node_modules/,
      },
    ],
  },
};

My previous issue it's solved!
const nodeExternals = require("webpack-node-externals");

module.exports = {
  mode: "development",
  target: "node",
  node: {
    __dirname: true,
  },
  externals: [nodeExternals()],
  module: {
    rules: [
      { test: /\.graphql?$/, loader: "webpack-graphql-loader" },
      {
        test: /\.js$/,
        use: {
          loader: "babel-loader",
          options: {
            presets: [["@babel/preset-env", { targets: { node: true } }]],
          },
        },
      },
    ],
  },
  resolve: { modules: ["src", "node_modules"] },
};

I encounter the same problem...using serverless-webpack to bundle the project and with prisma not found error.
serverless.yml
service: test-api

frameworkVersion: '2'
useDotenv: true

provider:
  name: aws
  runtime: nodejs12.x
  stage: dev
  region: ap-southeast-1
  apiName: test-api-dev
  tracing:
    apiGateway: true
    lambda: true
  environment:
    NODE_ENV: development
  iamRoleStatements:
    - Effect: 'Allow'
      Action:
        - 'xray:PutTraceSegments'
        - 'xray:PutTelemetryRecords'
      Resource:
        - '*'
  apiGateway:
    shouldStartNameWithService: true
    description: Test Api Staging
  lambdaHashingVersion: 20201221
  vpc:
    securityGroupIds:
      - xxx
    subnetIds:
      - xxx
  timeout: 30

package:
  individually: true

functions:
  main:
    handler: src/main/handler.main
    events:
      - http:
          path: /
          method: get
          cors: true

  login:
    handler: src/login/handler.login
    events:
      - http:
          path: /login
          method: post
          cors: true

  logout:
    handler: src/logout/handler.logout
    events:
      - http:
          path: /logout
          method: post
          cors: true

  authorize:
    handler: src/authorize/handler.authorize

  getSubOrders:
   ...

plugins:
  - serverless-webpack
  - serverless-prune-plugin
  # - serverless-plugin-typescript
  - serverless-offline
  - serverless-plugin-split-stacks

custom:
  webpack:
    webpackConfig: ./webpack.config.js
    includeModules: true
    packager: 'yarn'
    packagerOptions:
      scripts:
        - prisma generate
  prune:
    automatic: true
    number: 3

package.json
{
  "name": "test-api",
  "version": "0.1.0",
  "main": "app.js",
  "repository"<EMAIL_ADDRESS>  "author": "Donald Wu<EMAIL_ADDRESS>  "license": "MIT",
  "dependencies": {
    "@prisma/client": "^2.14.0",
    "aws-sdk": "^2.815.0",
    "aws-xray-sdk": "^3.2.0",
    "axios": "^0.21.1",
    "bcryptjs": "^2.4.3",
    "crypto": "^1.0.1",
    "dotenv": "^8.2.0",
    "jsonwebtoken": "^8.5.1",
    "lodash": "^4.17.20",
    "moment": "^2.29.1",
    "moment-timezone": "^0.5.32",
    "redis": "^3.0.2",
    "sidekiq": "^1.1.1",
    "uuid": "^8.3.2"
  },
  "devDependencies": {
    "@prisma/cli": "^2.14.0",
    "@types/aws-lambda": "^8.10.67",
    "@types/aws-sdk": "^2.7.0",
    "@types/bcryptjs": "^2.4.2",
    "@types/jest": "^26.0.19",
    "@types/jsonwebtoken": "^8.5.0",
    "@types/lambda-tester": "^3.6.1",
    "@types/lodash": "^4.14.165",
    "@types/moment-timezone": "^0.5.30",
    "@types/node": "^14.14.14",
    "@types/redis": "^2.8.28",
    "@types/serverless": "^1.78.19",
    "@types/uuid": "^8.3.0",
    "@typescript-eslint/eslint-plugin": "^4.11.0",
    "@typescript-eslint/parser": "^4.11.0",
    "aws-lambda": "^1.0.6",
    "codecov": "^3.8.1",
    "copy-webpack-plugin": "5.1.1",
    "eslint": "^7.16.0",
    "eslint-config-prettier": "^7.1.0",
    "eslint-plugin-prettier": "^3.3.0",
    "git-cz": "^4.7.6",
    "husky": "^4.3.6",
    "jest": "^26.6.3",
    "lambda-tester": "^4.0.1",
    "prettier": "^2.2.1",
    "serverless": "^2.19.0",
    "serverless-offline": "^6.8.0",
    "serverless-plugin-split-stacks": "^1.9.3",
    "serverless-plugin-typescript": "^1.1.9",
    "serverless-prune-plugin": "^1.4.3",
    "serverless-webpack": "5.3.1",
    "standard-version": "^9.0.0",
    "ts-jest": "^26.4.4",
    "ts-loader": "6.2.1",
    "ts-node": "^9.1.1",
    "typescript": "^4.1.3",
    "webpack": "4.41.4",
    "webpack-node-externals": "^2.5.2"
  },
  "scripts": {
    "dev": "serverless offline start",
    "deploy": "serverless deploy",
    "dashboard": "serverless dashboard",
    "package": "serverless package",
    "lint": "eslint '*/**/*.{ts,tsx}' --quiet --fix",
    "test": "jest --detectOpenHandles",
    "generate:prisma": "cd ./prisma && npx prisma introspect && npx prisma generate",
    "format:prisma": "cd ./prisma && npx prisma format",
    "prisma-studio": "npx prisma studio",
    "commit": "git-cz",
    "release": "standard-version"
  },
  "husky": {
    "hooks": {
      "pre-commit": "yarn lint && yarn run format:prisma",
      "pre-push": "yarn lint && yarn run format:prisma"
    }
  }
}

webpack.config.js
const path = require('path');
const slsw = require('serverless-webpack');
const isLocal = slsw.lib.webpack.isLocal;
const nodeExternals = require('webpack-node-externals');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = {
  mode: isLocal ? 'development' : 'production',
  devtool: isLocal ? 'source-map' : 'none',
  entry: slsw.lib.entries,
  target: 'node',
  resolve: {
    extensions: ['.mjs', '.ts', '.js'],
  },
  output: {
    libraryTarget: 'commonjs2',
    path: path.join(__dirname, '.webpack'),
    filename: '[name].js',
  },
  externals: [nodeExternals()],
  plugins: [new CopyWebpackPlugin(['./prisma/schema.prisma'])],
  module: {
    rules: [
      {
        test: /\.(tsx?)$/,
        loader: 'ts-loader',
        exclude: [
          [
            path.resolve(__dirname, 'node_modules'),
            path.resolve(__dirname, '.serverless'),
            path.resolve(__dirname, '.webpack'),
          ],
        ],
        options: {
          transpileOnly: true,
          experimentalWatchApi: true,
        },
      },
    ],
  },
};

with the above config, I am able to see the schema.prisma inside .serverless folder after I unzip the zip file.
hope this help some people here!

I encounter the same problem...using serverless-webpack to bundle the project and with prisma not found error.
serverless.yml
service: test-api

frameworkVersion: '2'
useDotenv: true

provider:
  name: aws
  runtime: nodejs12.x
  stage: dev
  region: ap-southeast-1
  apiName: test-api-dev
  tracing:
    apiGateway: true
    lambda: true
  environment:
    NODE_ENV: development
  iamRoleStatements:
    - Effect: 'Allow'
      Action:
        - 'xray:PutTraceSegments'
        - 'xray:PutTelemetryRecords'
      Resource:
        - '*'
  apiGateway:
    shouldStartNameWithService: true
    description: Test Api Staging
  lambdaHashingVersion: 20201221
  vpc:
    securityGroupIds:
      - xxx
    subnetIds:
      - xxx
  timeout: 30

package:
  individually: true

functions:
  main:
    handler: src/main/handler.main
    events:
      - http:
          path: /
          method: get
          cors: true

  login:
    handler: src/login/handler.login
    events:
      - http:
          path: /login
          method: post
          cors: true

  logout:
    handler: src/logout/handler.logout
    events:
      - http:
          path: /logout
          method: post
          cors: true

  authorize:
    handler: src/authorize/handler.authorize

  getSubOrders:
   ...

plugins:
  - serverless-webpack
  - serverless-prune-plugin
  # - serverless-plugin-typescript
  - serverless-offline
  - serverless-plugin-split-stacks

custom:
  webpack:
    webpackConfig: ./webpack.config.js
    includeModules: true
    packager: 'yarn'
    packagerOptions:
      scripts:
        - prisma generate
  prune:
    automatic: true
    number: 3

package.json
{
  "name": "test-api",
  "version": "0.1.0",
  "main": "app.js",
  "repository"<EMAIL_ADDRESS>  "author": "Donald Wu<EMAIL_ADDRESS>  "license": "MIT",
  "dependencies": {
    "@prisma/client": "^2.14.0",
    "aws-sdk": "^2.815.0",
    "aws-xray-sdk": "^3.2.0",
    "axios": "^0.21.1",
    "bcryptjs": "^2.4.3",
    "crypto": "^1.0.1",
    "dotenv": "^8.2.0",
    "jsonwebtoken": "^8.5.1",
    "lodash": "^4.17.20",
    "moment": "^2.29.1",
    "moment-timezone": "^0.5.32",
    "redis": "^3.0.2",
    "sidekiq": "^1.1.1",
    "uuid": "^8.3.2"
  },
  "devDependencies": {
    "@prisma/cli": "^2.14.0",
    "@types/aws-lambda": "^8.10.67",
    "@types/aws-sdk": "^2.7.0",
    "@types/bcryptjs": "^2.4.2",
    "@types/jest": "^26.0.19",
    "@types/jsonwebtoken": "^8.5.0",
    "@types/lambda-tester": "^3.6.1",
    "@types/lodash": "^4.14.165",
    "@types/moment-timezone": "^0.5.30",
    "@types/node": "^14.14.14",
    "@types/redis": "^2.8.28",
    "@types/serverless": "^1.78.19",
    "@types/uuid": "^8.3.0",
    "@typescript-eslint/eslint-plugin": "^4.11.0",
    "@typescript-eslint/parser": "^4.11.0",
    "aws-lambda": "^1.0.6",
    "codecov": "^3.8.1",
    "copy-webpack-plugin": "5.1.1",
    "eslint": "^7.16.0",
    "eslint-config-prettier": "^7.1.0",
    "eslint-plugin-prettier": "^3.3.0",
    "git-cz": "^4.7.6",
    "husky": "^4.3.6",
    "jest": "^26.6.3",
    "lambda-tester": "^4.0.1",
    "prettier": "^2.2.1",
    "serverless": "^2.19.0",
    "serverless-offline": "^6.8.0",
    "serverless-plugin-split-stacks": "^1.9.3",
    "serverless-plugin-typescript": "^1.1.9",
    "serverless-prune-plugin": "^1.4.3",
    "serverless-webpack": "5.3.1",
    "standard-version": "^9.0.0",
    "ts-jest": "^26.4.4",
    "ts-loader": "6.2.1",
    "ts-node": "^9.1.1",
    "typescript": "^4.1.3",
    "webpack": "4.41.4",
    "webpack-node-externals": "^2.5.2"
  },
  "scripts": {
    "dev": "serverless offline start",
    "deploy": "serverless deploy",
    "dashboard": "serverless dashboard",
    "package": "serverless package",
    "lint": "eslint '*/**/*.{ts,tsx}' --quiet --fix",
    "test": "jest --detectOpenHandles",
    "generate:prisma": "cd ./prisma && npx prisma introspect && npx prisma generate",
    "format:prisma": "cd ./prisma && npx prisma format",
    "prisma-studio": "npx prisma studio",
    "commit": "git-cz",
    "release": "standard-version"
  },
  "husky": {
    "hooks": {
      "pre-commit": "yarn lint && yarn run format:prisma",
      "pre-push": "yarn lint && yarn run format:prisma"
    }
  }
}

webpack.config.js
const path = require('path');
const slsw = require('serverless-webpack');
const isLocal = slsw.lib.webpack.isLocal;
const nodeExternals = require('webpack-node-externals');
const CopyWebpackPlugin = require('copy-webpack-plugin');

module.exports = {
  mode: isLocal ? 'development' : 'production',
  devtool: isLocal ? 'source-map' : 'none',
  entry: slsw.lib.entries,
  target: 'node',
  resolve: {
    extensions: ['.mjs', '.ts', '.js'],
  },
  output: {
    libraryTarget: 'commonjs2',
    path: path.join(__dirname, '.webpack'),
    filename: '[name].js',
  },
  externals: [nodeExternals()],
  plugins: [new CopyWebpackPlugin(['./prisma/schema.prisma'])],
  module: {
    rules: [
      {
        test: /\.(tsx?)$/,
        loader: 'ts-loader',
        exclude: [
          [
            path.resolve(__dirname, 'node_modules'),
            path.resolve(__dirname, '.serverless'),
            path.resolve(__dirname, '.webpack'),
          ],
        ],
        options: {
          transpileOnly: true,
          experimentalWatchApi: true,
        },
      },
    ],
  },
};

with the above config, I am able to see the schema.prisma inside .serverless folder after I unzip the zip file.
hope this help some people here!

I was able to bundle a vanilla app with prisma for Lambda with this webpack config without using /tmp or layers or anything else.
/// <reference path="./typings/webpack-permissions-plugin/index.d.ts" />

import glob from 'glob'
import path from 'path'
import { Configuration, IgnorePlugin } from 'webpack'
import { CleanWebpackPlugin } from 'clean-webpack-plugin'
import CopyPlugin from 'copy-webpack-plugin'
import PermissionsPlugin from 'webpack-permissions-plugin'

interface EntryOutput {
  entry: string
  output: {
    filename: string
    path: string
  }
}

const entries: EntryOutput[] = glob
  .sync('./src/handlers/*-handler.ts')
  .reduce((prev: EntryOutput[], curr: string): EntryOutput[] => {
    const filename = path.basename(curr, '.ts')
    return [
      ...prev,
      {
        entry: path.resolve(__dirname, curr),
        output: {
          filename: `${filename}.js`,
          path: path.resolve(__dirname, 'dist', filename),
        },
      },
    ]
  }, [])

const config: Configuration[] = entries.map(({ entry, output }) => ({
  entry,
  output: {
    ...output,
    libraryTarget: 'commonjs',
  },
  target: 'node',
  externals: {
    'aws-sdk': 'commonjs2 aws-sdk',
  },
  devtool: 'source-map',
  node: false,
  mode: 'production',
  resolve: {
    extensions: ['.ts', '.js', '.json'],
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  plugins: [
    new CleanWebpackPlugin(),
    new IgnorePlugin({
      resourceRegExp: /encoding/,
    }),
    new CopyPlugin({
      patterns: [
        {
          from: path.resolve(
            __dirname,
            './node_modules/.prisma/client/query-engine-rhel-openssl-1.0.x'
          ),
          to: output.path,
        },
        {
          from: path.resolve(
            __dirname,
            './node_modules/.prisma/client/schema.prisma'
          ),
          to: output.path,
        },
      ],
    }),
    new PermissionsPlugin({
      buildFiles: [
        {
          path: path.resolve(
            __dirname,
            `${output.path}/query-engine-rhel-openssl-1.0.x`
          ),
          fileMode: '755',
        },
      ],
    }),
  ],
}))

export default config

I have another issue open which I have worked around in this config https://github.com/prisma/prisma/issues/5250

I was able to bundle a vanilla app with prisma for Lambda with this webpack config without using /tmp or layers or anything else.
/// <reference path="./typings/webpack-permissions-plugin/index.d.ts" />

import glob from 'glob'
import path from 'path'
import { Configuration, IgnorePlugin } from 'webpack'
import { CleanWebpackPlugin } from 'clean-webpack-plugin'
import CopyPlugin from 'copy-webpack-plugin'
import PermissionsPlugin from 'webpack-permissions-plugin'

interface EntryOutput {
  entry: string
  output: {
    filename: string
    path: string
  }
}

const entries: EntryOutput[] = glob
  .sync('./src/handlers/*-handler.ts')
  .reduce((prev: EntryOutput[], curr: string): EntryOutput[] => {
    const filename = path.basename(curr, '.ts')
    return [
      ...prev,
      {
        entry: path.resolve(__dirname, curr),
        output: {
          filename: `${filename}.js`,
          path: path.resolve(__dirname, 'dist', filename),
        },
      },
    ]
  }, [])

const config: Configuration[] = entries.map(({ entry, output }) => ({
  entry,
  output: {
    ...output,
    libraryTarget: 'commonjs',
  },
  target: 'node',
  externals: {
    'aws-sdk': 'commonjs2 aws-sdk',
  },
  devtool: 'source-map',
  node: false,
  mode: 'production',
  resolve: {
    extensions: ['.ts', '.js', '.json'],
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  plugins: [
    new CleanWebpackPlugin(),
    new IgnorePlugin({
      resourceRegExp: /encoding/,
    }),
    new CopyPlugin({
      patterns: [
        {
          from: path.resolve(
            __dirname,
            './node_modules/.prisma/client/query-engine-rhel-openssl-1.0.x'
          ),
          to: output.path,
        },
        {
          from: path.resolve(
            __dirname,
            './node_modules/.prisma/client/schema.prisma'
          ),
          to: output.path,
        },
      ],
    }),
    new PermissionsPlugin({
      buildFiles: [
        {
          path: path.resolve(
            __dirname,
            `${output.path}/query-engine-rhel-openssl-1.0.x`
          ),
          fileMode: '755',
        },
      ],
    }),
  ],
}))

export default config

I have another issue open which I have worked around in this config https://github.com/prisma/prisma/issues/5250

@sheldonj

Does someone have a working boilerplate of this somewhere I could inspect. Im still struggling at bit. Or could maybe spot something I'm doing wrong....
And then the build on our CI server fails with an error like this. So something clearly wrong with my webpack config, or maybe the versions of dependencies are out of sync?
Serverless: Packing external modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>[10:25:55][Step 5/6]
[10:25:55][Step 5/6]   Error --------------------------------------------------
[10:25:55][Step 5/6]
[10:25:55][Step 5/6]   Error: npm run script0 failed with code 1
[10:25:55][Step 5/6]       at ChildProcess.<anonymous> (/data/teamcity/work/308be0f63058d463/node_modules/serverless-webpack/lib/utils.js:91:16)
[10:25:55][Step 5/6]       at ChildProcess.emit (events.js:310:20)
[10:25:55][Step 5/6]       at ChildProcess.EventEmitter.emit (domain.js:482:12)
[10:25:55][Step 5/6]       at maybeClose (internal/child_process.js:1021:16)
[10:25:55][Step 5/6]       at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)

Did you ever figure this out? I'm getting the same error as you, with a similar setup:
"dependencies": {
    "@prisma/client": "2.17.0",
    "apollo-server-lambda": "^2.21.0",
    "copy-webpack-plugin": "^7.0.0",
    "graphql": "^15.5.0",
    "graphql-iso-date": "^3.6.1",
    "nexus": "^1.0.0",
    "source-map-support": "^0.5.19"
  },
  "devDependencies": {
    "@babel/core": "^7.12.17",
    "@babel/preset-env": "^7.12.17",
    "@prisma/cli": "^2.17.0",
    "babel-loader": "^8.2.2",
    "babel-plugin-source-map-support": "^2.1.3",
    "prisma": "2.17.0",
    "serverless-dotenv-plugin": "3.5.1",
    "serverless-offline": "^6.8.0",
    "serverless-webpack": "^5.3.5",
    "webpack": "^5.23.0",
    "webpack-node-externals": "^2.5.2"
  },

.babelrc
{
"plugins": ["source-map-support"],
  "presets": [
    ["@babel/preset-env", { "targets": { "node": "12" } }]
  ]
}

webpack config
const path = require("path");
const slsw = require("serverless-webpack");
const nodeExternals = require("webpack-node-externals");
const CopyWebpackPlugin = require("copy-webpack-plugin");

module.exports = {
  entry: slsw.lib.entries,
  target: "node",
  devtool: "source-map",
  // node: false,
  externals: [nodeExternals()],
  output: {
    libraryTarget: "commonjs2",
    path: path.join(__dirname, ".webpack"),
    filename: "[name].js",
    sourceMapFilename: '[file].map'
  },
  mode: slsw.lib.webpack.isLocal ? "development" : "production",
  optimization: {
    minimize: false,
  },
  plugins: [
    new CopyWebpackPlugin({ patterns: ["./prisma/schema.prisma"] }),
  ],
  module: {
    rules: [
      {
        test: /\.js$/,
        loader: "babel-loader",
        include: __dirname,
        exclude: /node_modules/,
      },
    ],
  },
};

serverless.yml

package:
  individually: true

plugins:
  - serverless-dotenv-plugin
  - serverless-webpack
  - serverless-offline

custom:
  webpack:
    webpackConfig: "webpack.config.js"
    includeModules: true # This is required
    keepOutputDirectory: true
    packager: "npm"
    packagerOptions:
      scripts: # this is the magic
        - prisma generate

Try to downgrade webpack to 4 version and all it deps, like copy-webpack-plugin to 6.4.0 to support webpack v4

I followed the notes of @dested but currently getting the same error that recent people are having above:
child exited with code 1

Any ideas? working repos?
This issue is almost a year old, weird that it is still open.

For everyone having issues with:
Error: npm run script0 failed with code 1
Please check if prisma cli is available on the environment or try to replace this:
  webpack:
    webpackConfig: ./webpack.config.js
    includeModules: true
    packagerOptions:
      scripts: # this is the magic
        - prisma generate

For this:
  webpack:
    webpackConfig: ./webpack.config.js
    includeModules: true
    packagerOptions:
      scripts: # this is the magic
        - npx prisma generate

on your serverless.yml file, since most likely the "prisma generate" command is failing.
Also, please note that whoever is using "copy-webpack-plugin" on version 6 should replace on your webpack configuration
  plugins: [
    new CopyWebpackPlugin(['./prisma/schema.prisma']), // without this the prisma generate above will not work
  ],

for this:
  plugins: [
    new CopyWebpackPlugin(
      {
        patterns: [
          { from: './prisma/schema.prisma'}, // without this the prisma generate above will not work
        ]
      }
    ),
  ],

since the plugin had a breaking change explained here

@Brenopms That also did not work sadly"
  Error: yarn install --non-interactive failed with code 1
      at ChildProcess.<anonymous> (/home/omar/Desktop/Graphql-API-Prisma2-CodeFirst/node_modules/serverless-webpack/lib/utils.js:91:16)
      at ChildProcess.emit (events.js:315:20)
      at ChildProcess.EventEmitter.emit (domain.js:486:12)
      at maybeClose (internal/child_process.js:1048:16)
      at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)

So I did a little investigation, please check this:
https://github.com/serverless-heaven/serverless-webpack/issues/690#issuecomment-803466455

Any update on this? Was anyone able to find a fix for this issue?
Error: npm install failed with code 1
      at ChildProcess.<anonymous> (/Users/carlosherrera/Workspace/Pickboxx/pickboxx-backend/node_modules/serverless-webpack/lib/utils.js:91:16)
      at ChildProcess.emit (node:events:376:20)
      at ChildProcess.EventEmitter.emit (node:domain:470:12)
      at maybeClose (node:internal/child_process:1055:16)
      at Socket.<anonymous> (node:internal/child_process:441:11)
      at Socket.emit (node:events:376:20)
      at Socket.EventEmitter.emit (node:domain:470:12)
      at Pipe.<anonymous> (node:net:661:12)

Please open a new issue about this @carlosherrera1113 and provide all information. This issue here is full with all kinds of different problems, and we will not be able to debug your problem really here. THanks.

 Two days wasted of trying to deploy a TypeScript / Prisma / Serverless app to AWS Lambda.. It really shouldn't be that hard. Problem lies around copying the Prisma client including the binaries into the deployment package which is not all that transparent.
In the end this module saved me:
https://www.npmjs.com/package/serverless-webpack-prisma
This is the results of my efforts: A working deployable bare-bones AWS Lambda function using TypeScript, Prisma and Amazon Aurora RDS PostgresQL.
https://github.com/ChristianRich/prisma-postgresql-typescript-setup/tree/feature/serverless
Feel free to take it for a spin.

Clone the repo (use the feature branch /feature/serverless)
Install deps with npm i
Add your PostgresQL connection string to .env (see .env.sample)
Run sample migration npx prisma generate or npm run prisma:generate
Run the seed script with sample records npm run db:seed (creating two user records Alice and Bob)
Deploy to AWS sls deploy
Copy the API Gateway URL from the Serverless output in the console to Postman e.g  https://xxxxxxxxxx.execute-api.ap-southeast-2.amazonaws.com/dev/users/all

On my end this produces the following:
[
    {
        "id": 1,
        "email"<EMAIL_ADDRESS>        "name": "Alice",
        "status": "unverified",
        "posts": [],
        "profile": null
    },
    {
        "id": 2,
        "email"<EMAIL_ADDRESS>        "name": "Bob",
        "status": "unverified",
        "posts": [],
        "profile": null
    }
]

I was able to bundle a vanilla app with prisma for Lambda with this webpack config without using /tmp or layers or anything else. Key things were setting node to false and modifying the permissions for the binary. Hope it helps someone
/// <reference path="./typings/webpack-permissions-plugin/index.d.ts" />

import glob from 'glob'
import path from 'path'
import { Configuration, IgnorePlugin } from 'webpack'
import { CleanWebpackPlugin } from 'clean-webpack-plugin'
import CopyPlugin from 'copy-webpack-plugin'
import PermissionsPlugin from 'webpack-permissions-plugin'

interface EntryOutput {
  entry: string
  output: {
    filename: string
    path: string
  }
}

const entries: EntryOutput[] = glob
  .sync('./src/handlers/*-handler.ts')
  .reduce((prev: EntryOutput[], curr: string): EntryOutput[] => {
    const filename = path.basename(curr, '.ts')
    return [
      ...prev,
      {
        entry: path.resolve(__dirname, curr),
        output: {
          filename: `${filename}.js`,
          path: path.resolve(__dirname, 'dist', filename),
        },
      },
    ]
  }, [])

const config: Configuration[] = entries.map(({ entry, output }) => ({
  entry,
  output: {
    ...output,
    libraryTarget: 'commonjs',
  },
  target: 'node',
  externals: {
    'aws-sdk': 'commonjs2 aws-sdk',
  },
  devtool: 'source-map',
  node: false,
  mode: 'production',
  resolve: {
    extensions: ['.ts', '.js', '.json'],
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  plugins: [
    new CleanWebpackPlugin(),
    new IgnorePlugin({
      resourceRegExp: /encoding/,
    }),
    new CopyPlugin({
      patterns: [
        {
          from: path.resolve(
            __dirname,
            './node_modules/.prisma/client/query-engine-rhel-openssl-1.0.x'
          ),
          to: output.path,
        },
        {
          from: path.resolve(
            __dirname,
            './node_modules/.prisma/client/schema.prisma'
          ),
          to: output.path,
        },
      ],
    }),
    new PermissionsPlugin({
      buildFiles: [
        {
          path: path.resolve(
            __dirname,
            `${output.path}/query-engine-rhel-openssl-1.0.x`
          ),
          fileMode: '755',
        },
      ],
    }),
  ],
}))

export default config

I have another issue open which I have worked around in this config #5250

You save me. Thank you so much.

Hi everyone!
Just wanted to provide an update in this thread. We don't believe this is a bug in Prisma, per se, but it's also not a feature. Unfortunately the issues we've been seeing with bundlers (webpack, esbuild, etc) is due to files that Prisma needs to function not being copied into resulting bundles.
To that end, we are looking to improve our documentation so that future individuals don't have to tread down the same very painful path that y'all have.
Our first pass at this is live. Please check out our new documentation on deploying with Serverless Framework and let us know what you think.

Hi there!
Here's one approach to address this issue: place the query engine in the same directory as your serverless function file. To do this, follow these steps:

Begin by incorporating the relevant engine into your prisma schema.
Ensure that it is downloaded by running the command prisma generate.
Afterward, copy the appropriate engine to the bundles folder if you are utilizing a bundler such as Webpack, or directly into the folder of your Lambda function.
Do not forget to copy your prisma.schema also.

Here is an example with copy-webpack-plugin


Sync error after deleting one event of periodical events (EWS)

Select EWS periodical event and delete it. Sync will display the following error.
{"error":"Cannot read property \"__id\" from undefined"}


minor fixes

@bqpd, this is ready to review pending Jenkins. Addresses comments in #454

ready for re-review

Looks good!

Shoot, I think I broke master. @galbramc the CI on master reports "aborted"

no I am changing things on jenkins. Because of the 'globa' $HOME/.gpkit folder you cannot have multiple tests running at the same time on any given machine. I realized that I need to make sure the gpkit_Push and gpkit_PullRequests could not be running at the same time. I found a plugin that was even better. It allows me to restrict things so no two jobs can run at the same time on a given machine, but jobs can run in parallel across machines. Before your builds were running in serial across all machines, but now you are parallel across machines and serial on a given machine.

awesome!!

Nifty! (looking forward to removing $HOME/.gpkit)

Yes. If you remove $HOME/.gpkit so that each build is completely independent, then we can run all builds completely in parallel. Should you open an issue maybe about this?

I believe that is captured in #315 .

Yes it is.

Actually, I think you can check off that first goal. You are no longer mucking with a users .bashrc or .bash_profile, so no need to ask for permission.


Add Formyfi DApp to showcase

Thank you for your contribution to the IC Developer Portal.
Before submitting your Pull Request, please make sure that:

[x] You have updated the .github/CODEOWNERS file according to your changes.
[x] You have registered new documents to /sidebars.js if any.

Dear @TDarkDev,
In order to potentially merge your code in this open-source repository and therefore proceed with your contribution, we need to have your approval on DFINITY's CLA.
If you decide to agree with it, please visit this issue and read the instructions there. Once you have signed it, re-trigger the workflow on this PR to see if your code can be merged.
— The DFINITY Foundation

Thank you for your contribution to the IC Developer Portal. Before submitting your Pull Request, please make sure that:

[x]  You have updated the .github/CODEOWNERS file according to your changes.
[x]  You have registered new documents to /sidebars.js if any.

@TDarkDev Can you please compress the logo file size? We have a restriction of 200 MB for the logo file size.

@TDarkDev, we will add this on the ecosystem page in our own PR with the adjusted image size. Thank you.


Support RPC 0.2.1 + drop deploy transaction

Describe your changes
This PR introduces support for RPC 0.2.1 spec and drops support for deploy transaction (gateway + rpc).
Linked issues
Closes https://github.com/software-mansion/starknet-jvm/issues/146
Closes https://github.com/software-mansion/starknet-jvm/issues/148
Closes https://github.com/software-mansion/starknet-jvm/issues/190
Closes https://github.com/software-mansion/starknet-jvm/issues/184
Closes https://github.com/software-mansion/starknet-jvm/issues/202
Breaking changes

[X] This issue contains breaking changes

RPC 0.1.0 support is dropped

provider.deployContract is dropped

Codecov Report
Base: 70.53% // Head: 69.33% // Decreases project coverage by -1.20% :warning:

Coverage data is based on head (61176a6) compared to base (6e65c4c).
Patch coverage: 53.35% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #212      +/-   ##
==========================================
- Coverage   70.53%   69.33%   -1.21%
==========================================
  Files          53       55       +2
  Lines        1541     1722     +181
  Branches      109      113       +4
==========================================
+ Hits         1087     1194     +107
- Misses        424      495      +71
- Partials       30       33       +3

Impacted Files
Coverage Δ

...lin/com/swmansion/starknet/data/types/Responses.kt
21.95% <8.10%> (-25.59%)
:arrow_down:

...knet/data/types/transactions/TransactionReceipt.kt
22.22% <9.67%> (+5.40%)
:arrow_up:

.../kotlin/com/swmansion/starknet/data/types/Event.kt
31.57% <33.33%> (+1.57%)
:arrow_up:

...lin/com/swmansion/starknet/data/types/Contracts.kt
52.87% <40.74%> (+10.48%)
:arrow_up:

...kotlin/com/swmansion/starknet/provider/Provider.kt
33.33% <50.00%> (+13.33%)
:arrow_up:

...knet/provider/exceptions/RequestFailedException.kt
50.00% <50.00%> (-50.00%)
:arrow_down:

...lin/com/swmansion/starknet/data/types/Execution.kt
79.54% <59.25%> (-2.72%)
:arrow_down:

...on/starknet/data/types/transactions/Transaction.kt
72.19% <61.11%> (-1.44%)
:arrow_down:

.../JsonRpcTransactionReceiptPolymorphicSerializer.kt
54.54% <66.66%> (+4.54%)
:arrow_up:

...pcGetBlockWithTransactionsPolymorphicSerializer.kt
75.00% <75.00%> (ø)

... and 16 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Provide API specification

It would be helpful to have an API specification (ex. Swagger) for consumer/provider controllers.

related to #46. We will work on that and provide a specification with the first release.


Continue GCing other repos on error in one repo

The current code propagates all errors up to the iteration step meaning that a single malformed repo will prevent GC of other repos.
This PR simply stops that propagation.
Fix #21605
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@1ee1147). Click here to learn what that means.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##             main   #22422   +/-   ##
=======================================
  Coverage        ?   48.20%
=======================================
  Files           ?     1044
  Lines           ?   142368
  Branches        ?        0
=======================================
  Hits            ?    68633
  Misses          ?    65566
  Partials        ?     8169

Impacted Files
Coverage Δ

services/repository/check.go
0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

make LG-TM work


Fix warnings and simplify canonicalizer code

Coverage decreased (-0.71%) to 90.47% when pulling 09fc72a9e09c171a8b05281a3077a1664468c59e on fmela:master into 4c1f3abfb2bce9b77b80ef90fa03b537d7cae3e6 on smola:master.

Not sure how to proceed from here regarding the loss in coverage.

@fmela Thank you! These changes look really good. Merging.


JavaScript Intellisense Not working

As of yesterday i opened my project and started writing some code, there wasn't any suggestion in vsc so i thought it would a be bug that could be resolved with restarting PC. i neglected that and today i facing same problem.
i have Re-installed Vscode but the problem is not resolved

VS Code Version:
latest
OS Version:
windows 10

Please let me know if more Information is needed

Please launch the Start Extension Bisect command from the Command Palette (F1) to investigate whether one of your extensions is causing this.

I tried this. And some other extension were having conflicts, this resolved the problem 👍. Thanks!


Monitor wraparound with multiple windows of one application on different monitors is inconsistent

Don't really know how to describe this, so I'll just tell you how to recreate the issue.
Each scenario has three monitors (1, 2, 3) and two applications (A, B). There is one tiled window on every monitor.
Scenario 1:

Desktop on monitor 1 has a window of application A.
Desktop on monitor 2 has a window of application A.
Desktop on monitor 3 has a window of application B.
Starting at monitor 1, cycling with next goes in order 1 -> 2 -> 3 -> 1 -> 2 -> 3 (correct)
Starting at monitor 1, cycling with prev goes in order 1 -> 3 -> 1 -> 3 -> 1 -> 3 (incorrect)

Scenario 2:

Desktop on monitor 1 has a window of application A.
Desktop on monitor 2 has a window of application B.
Desktop on monitor 3 has a window of application A.
Starting at monitor 1, cycling with next goes in order 1 -> 2 -> 1 -> 2 -> 1 -> 2 (incorrect)
Starting at monitor 1, cycling with prev goes in order 1 -> 3 -> 2 -> 1 -> 3 -> 2 (correct)

Scenario 3:

Desktop on monitor 1 has a window of application B.
Desktop on monitor 2 has a window of application A.
Desktop on monitor 3 has a window of application A.
Starting at monitor 1, cycling with next goes in order 1 -> 2 -> 3 -> 1 -> 2 -> 3 (correct)
Starting at monitor 1, cycling with prev goes in order 1 -> 3 -> 1 -> 3 -> 1 -> 3 (incorrect)

Any idea how and why this happens?
Edit/ To expand on this, I know there are existing issues here. Monitor activation works through activating target application on that monitor which often jumps back to another monitor, because that application has another window on there that was last used. This issue is solely for the inconsistency with the monitor wraparound functionality.

@dominiklohmann I have to admit I have not spent time investigating this issue yet, however to expand some regarding focusing in general..

Edit/ To expand on this, I know there are existing issues here. Monitor activation works through activating target application on that monitor which often jumps back to another monitor, because that application has another window on there that was last used. This issue is solely for the inconsistency with the monitor wraparound functionality.

I have managed to solve this problem - again we have to rely on the scripting addition. I have managed to locate a function inside the Dock.app that activates a window given its windowid and psn. This way of activation bypasses the issue that we see when using the accessibility API or the lower-level CPS API (CPSSetFrontProcessWithOptions). I have not yet integrated it with chunkwm, but the functionality has been added to the chunkwm-sa repository.

This is great news. Played around with this for a bit and the focusing seems to work nicely.


Make flash fallback take a path relative to the HTML file

When flashmediaelement.swf receives a file as a flashvar parameter, make it relative to the HTML page that contains the flashmediaelement.swf plugin, rather than relative to the flashmediaelement.swf file.
Here is what we need today, if the video.mp4 file is in the same directory than the HTML file, but the flashmediaelement.swf is in a different directory:
<video width="320" height="240" controls="controls">
  <source src="video.mp4" type="video/mp4"/>
  <object width="320" height="240" type="application/x-shockwave-flash" data="../scripts/flashmediaelement.swf">
    <param name="movie" value="../scripts/flashmediaelement.swf" />
    <param name="flashvars" value="controls=true&file=../pages/video.mp4" />
  </object>
</video>

Here would be a more logical solution:
<video width="320" height="240" controls="controls">
  <source src="video.mp4" type="video/mp4"/>
  <object width="320" height="240" type="application/x-shockwave-flash" data="../scripts/flashmediaelement.swf">
    <param name="movie" value="../scripts/flashmediaelement.swf" />
    <param name="flashvars" value="controls=true&file=video.mp4" />
  </object>
</video>

Notice that the only change is the file parameter in the <param name="flashvars" line.
Benefits:
This would make it seamlessly usable for browsers with javascript disabled, as it would allow to use the same path as the one in src of the <source> tag. Otherwise, I would need to compute it manually or with a php script each time. Also it would be easier to move flashmediaelement.swf to another directory.

Unfortunately, Flash can't know where the HTML file is unless you also send
that as a parameter and then have it calculate where the video it is based
on that.
On Wed, Oct 21, 2015 at 1:27 PM, jlgrall<EMAIL_ADDRESS>wrote:

When flashmediaelement.swf receives a file as a flashvar parameter,
make it relative to the HTML page that contains the
flashmediaelement.swf plugin, rather than relative to the
flashmediaelement.swf file.
Here is what we have today, if the video.mp4 file is in the same
directory than the HTML file, but the flashmediaelement.swf is in a
different directory:

Here is the more logical solution:

Notice that the only change is the file parameter in the <param
name="flashvars" line.
Benefits:
This would make it seamlessly usable for browsers with javascript
disabled, as it would allow to use the same path as the one in src of the
 tag. Otherwise, I would need to compute it manually or with a
php script each time. Also it would be easier to move
*flashmediaelement.swf* to another directory.
—
Reply to this email directly or view it on GitHub
https://github.com/johndyer/mediaelement/issues/1629.

--
John Dyer - http://j.hn/

Yep, sending the url of the page as a parameter would defeat the purpose, because if we add the url of the page, we could just as simply remove the page's filename and prepend it to the movie path.
But Flash could query the html page's url like this:
import flash.external.ExternalInterface;

var url:String = ExternalInterface.call("window.location.pathname.toString");
if (url) ...

And it could use another parameter name to differentiate from the current behavior. For exemple: path, url or relFile.

@jlgrall Is this still an issue?

Closing this issue since it has been more than weeks with no answer. Please feel free to reopen bug if it still appears


[Suggestion] Discussions tab for general help

Just as a simple suggestion, I'm wondering if there can be a discussion tab to post problems with running the system as opposed to posting individual issues. This can keep it more organized, and it's easier to track common threads. A simple point of comparison would be the discussion structure on the grok repository. Thoughts?

Good idea, I tried to turn it on. I haven't used this before, let me know if it looks wrong somehow.

I think it looks perfect. Maybe worth making a small PSA to move all general help questions to discussions as people are still posting in issues?


Error on app engine deploy

Hello , I was trying with "Hello World" app for .net core and is failing at last step when trying to deploy to app engine flex with below error.
Updating service [default] (this may take several minutes)...failed.
ERROR: (gcloud.app.deploy) Error Response: [13] An internal error occurred.
I cant find anything in logging too. please can you let me know what wrong I am doing here as I just cloned the repo and built it.

I'll take a look tomorrow and let you know.

I'll take a look tomorrow and let you know.

Just for extra information, can you add the link with the instructions you are following to deploy? Or a description of exactly how you are trying to deploy. Thanks

Just for extra information, can you add the link with the instructions you are following to deploy? Or a description of exactly how you are trying to deploy. Thanks

sure,

so I cloned the "Hello World" repo from github
Open it in Visual studio and change the "Copy to Output Directory" Property to Copy if Newer.
Build the solution in release mode
Open google sdk cmd and change directory to HelloWorld\bin\Release\netcoreapp2.1
lastly, gcloud app deploy

Also I tried "Publish to Google Cloud" plugin in VS and it failed too with same error
Updating service [default] (this may take several minutes)...
..................................failed.
ERROR: (gcloud.app.deploy) Error Response: [13] An internal error occurred.
Failed to deploy project HelloWorld to App Engine Flex.

sure,

so I cloned the "Hello World" repo from github
Open it in Visual studio and change the "Copy to Output Directory" Property to Copy if Newer.
Build the solution in release mode
Open google sdk cmd and change directory to HelloWorld\bin\Release\netcoreapp2.1
lastly, gcloud app deploy

Also I tried "Publish to Google Cloud" plugin in VS and it failed too with same error
Updating service [default] (this may take several minutes)...
..................................failed.
ERROR: (gcloud.app.deploy) Error Response: [13] An internal error occurred.
Failed to deploy project HelloWorld to App Engine Flex.

Thanks for the info. I'll try to reproduce tomorrow and report back here with my findings.

Thanks for the info. I'll try to reproduce tomorrow and report back here with my findings.

I just successfully deployed the HelloWorld for App Engine app and was able to access it with my browser.
Can I double check that you have followed the instructions on the README file for the project? Specially the instructions on the first step of the prerequisites and in particular all the steps around the creation of a service account key.
Notice that if you created the env var with the Google Cloud SDK shell already opened, that process won't pick up the env var. You need to open a new Google Cloud SDK shell after you have created the env var.

I just successfully deployed the HelloWorld for App Engine app and was able to access it with my browser.
Can I double check that you have followed the instructions on the README file for the project? Specially the instructions on the first step of the prerequisites and in particular all the steps around the creation of a service account key.
Notice that if you created the env var with the Google Cloud SDK shell already opened, that process won't pick up the env var. You need to open a new Google Cloud SDK shell after you have created the env var.

Can I ask also, in which region you are running? We've seen similar problems a couple of times (https://github.com/googleapis/google-cloud-dotnet/issues/4903) in regions that are running low on resources. In that case, changing to a different region might be a temporary workaround.

Can I ask also, in which region you are running? We've seen similar problems a couple of times (https://github.com/googleapis/google-cloud-dotnet/issues/4903) in regions that are running low on resources. In that case, changing to a different region might be a temporary workaround.

Thanks for the response. I'll definitely try again this evening. The region I was pointing to is europe-west2.

Thanks for the response. I'll definitely try again this evening. The region I was pointing to is europe-west2.

I just read the other thread, and will try with different region too

I just read the other thread, and will try with different region too

I just read the other thread, and will try with different region too

I just read the other thread, and will try with different region too

So I just tried it again, I was able to deploy successfully for us-central1 but europe-west2 is still failing.  Hope the issue gets fixed soon. Thanks for your help

So I just tried it again, I was able to deploy successfully for us-central1 but europe-west2 is still failing.  Hope the issue gets fixed soon. Thanks for your help

Thanks for getting back to us. I'll be closing this issue now because there's no problem with the sample itself which is what we can help with.

Thanks for getting back to us. I'll be closing this issue now because there's no problem with the sample itself which is what we can help with.


INFINITY-2185: Refactor DefaultScheduler/DefaultService construction (API CHANGE)

For developers, the main changes are:

Renaming DefaultScheduler.Builder to SchedulerBuilder (dev-facing interface otherwise remains pretty similar)
Renaming DefaultService to SchedulerRunner (existing constructors would be switched to new static methods, but also remains pretty similar)

For examples of how these changes would look for developers, see frameworks/*/Main.java in this PR.
Overview of changes:

Breaks out DefaultScheduler.Builder into a dedicated SchedulerBuilder class:

External interface itself is largely intact, the changes are just marking some de-facto internals as private and otherwise extracting construction-specific code from DefaultScheduler itself.

Renames DefaultService to SchedulerRunner:

Adds a set of static methods to be used for construction
A lot of internal refactoring to improve startup logic.
One notable fix is ensuring that we establish a ZK lock before triggering any other ZK access.

Other misc fixes brought along for the ride:

Renames RLimit to RLimitSpec and moves it adjacent to the other *Spec types. Shouldn't introduce any upgrade compatibility problems as the RLimit class name is not included in serialized ServiceSpecs (verified with an Elastic install).
Removes unused Reconciler.forceComplete() call.
Removes unused SchedulerState class.
Moves DeploymentType handling from ConfigurationUpdater.UpdateResult into StateStoreUtils where it's actually being used.

I actually added you in hopes that you'd point out the clunky parts :)

Ping, any other comments? Technically doesn't have approval yet. Lets see if it passes CI now..


Scarab fragments

Update the Fragment stash tab background and positions
Add the Scarabs to the Fragment Stash tab viewmodel.
Before I continue with the scarabs I need some more info @thailyn:
Rank placements:
Rusted, Polished, Gilded (Left to right)
Effect Placements:
Which effect where!
If anyone has a fragment tab with some of each grade of scarab i would be very appreciative as:

I don't have a fragment stash tab
I don't have a single scarab yet! (Still on lvl 50 on one char)

Needs #908 merging first

CurrencyStash.xaml.cs(49,103): error CS1061: 'Colour' does not contain a definition for 'WpfColor' and no extension method 'WpfColor' accepting a first argument of type 'Colour' could be found (are you missing a using directive or an assembly refe

Looks like I will have to revisit this until other PR's are merged in.

Closing this because i've fucked up. Git noob here....


Thanks!

Did not work because you are not in the GitHub Actions beta.  :-(  Actions ship on Nov. 14th.
Thanks anyway.


chef convergence is not updating the node run_list

Hi,
I've read the related threads on the QT-DevOps but couldn't find the answer. So, I am posting it my questions

I have manually converged the node after the initial berks upload and could verify the items in the cookbook recipe on the node. Later, I made changes to the recipe, updated version in metadata.rb and performed a berks upload. After that I logged into chef server and updated the node with latest version of the cookbook and waited for the convergence to happen. however it did not happen after waiting for couple of hours. I then tried manual convergence and it worked. I am trying to understand why it did not pick the updated run_list?
I tried using knife status to see when it last converged, is there a different command?

To view the versions of the cookbook I tried few commands but not successful. The closet command is knife cookbook show COOKBOOK [version] [..] [...] (options). can anyone reply if they are able see the versions?

Thanks in advance!

try these commands
knife search -i 'cookbooks:your-cookbook' -a cookbooks.your-cookbook.version
or
knife node show <node-name> -a base_cookbook.cookbook_versions
if your resolve the issue. please close the issue otherwise update the issue.

Hi @srmanikanta , thank you for your response.
knife search -i 'cookbooks:your-cookbook' -a cookbooks.your-cookbook.version  - when run is displaying the node information and this command is asking us to pass version info
I am trying to get the list of all the versions. e,g when we run knife cookbook list it displays the list of all cookbooks. Likewise I am trying to find a command which returns list of cookbook versions.
The other command also displaying the same info..
Aplogies, if I had not made my question clear. All I want is

to get list of versions associated with the cookbook ?
command to see convergence info?

TIA

hi vinodmaddela, please try this command
knife node show <node-name> -a cookbooks
just pass your node name in

I think this is useful to you, if not please ignore.

Thanks @srmanikanta ,  but it isn't really helping.
can we wait for couple of days for others to respond with their inputs and then close it?

List of version associated with the cookbook can be viewed
knife cookbook show

Can  you use the chef_client supermarket cookbook and change the convergance to 10 mins and see whether its executed or not on chef server. Use hosted chef-server reports section

List of version associated with the cookbook can be viewed
knife cookbook show

Hi @sharmatanmaya , @srmanikanta  thank you for the input.
I am able to see the list of cookbook versions in UI; please refer to the screen

But I was actually looking for a command to view the version in cmd and the command is
knife cookbook show cookbook_name --list Please refer to the screen

Thank you!

Can you use the chef_client supermarket cookbook and change the convergance to 10 mins and see whether its executed or not on chef server. Use hosted chef-server reports section

Sir @shaikkhajaibrahim , the convergence is happening now.. Thank you !


feat: Adds related dashboards tab to the Table detail page

Summary of Changes
Adds a related dashboards tab on the Table detail page
Tests
Added some basic tests to table detail
Added tests to the helper functions

CheckList
Make sure you have checked all steps below to ensure a timely review.

[ ] PR title addresses the issue accurately and concisely. Example: "Updates the version of Flask to v1.0.2"

In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

[ ] PR includes a summary of changes, including screenshots of any UI changes.
[ ] PR adds unit tests, updates existing unit tests, OR documents why no test additions or modifications are needed.
[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public python functions and the classes in the PR contain docstrings that explain what it does

[ ] PR passes all tests documented in the developer guide

Codecov Report

Merging #470 into master will decrease coverage by 4.04%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #470      +/-   ##
==========================================
- Coverage   79.49%   75.45%   -4.05%
==========================================
  Files         216       42     -174
  Lines        5365     1715    -3650
  Branches      696      159     -537
==========================================
- Hits         4265     1294    -2971
+ Misses       1042      376     -666
+ Partials       58       45      -13

Impacted Files
Coverage Δ

...js/components/TableDetail/OwnerEditor/constants.ts

...on/static/js/components/AnnouncementPage/index.tsx

...tic/js/components/TableDetail/SourceLink/index.tsx

...ic/js/components/SearchPage/SearchFilter/index.tsx

...ic/js/components/DashboardPage/ChartList/index.tsx

...tic/js/components/common/ResourceList/constants.ts

...sen_application/static/js/utils/navigationUtils.ts

...undsen_application/static/js/ducks/issue/api/v0.ts

...on/static/js/components/common/SearchBar/index.tsx

...tatic/js/components/common/ScrollTracker/index.tsx

... and 160 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 083b9b5...4854946. Read the comment docs.

Minor comment on visuals, and feel free to merge. Now that lists are in a TabsComponent where the tab headers have a bottom border, let's apply something like
  .right-panel {
    .tabs-component {
      .tab-content .list-group-item:first-child {
        border-top: none;
      }
    }
  }

in components/TableDetail/styles.scss to avoid the double-thick border under the tab headers.

Good catch!
I updated the styles and removed the specific one for the dashboard detail page.


ockam_app crate should use new Identity design

Part of #5543

It's not clear if anything needs to be done at all, since ockam_app uses ockam_api/ockam_command. The best scenario is that migrating those create is enough. Closing for now, may be reopened if during testing phase we discover that something is required to make this work


Upgrade to bevy 0.12

Hey, thanks for this awesome crate!
I wanted to use it in a bevy 0.12 project so quickly upgraded it.
Also, I don't know why it was using a patched version of dolly? I just upgraded it to use the crates.io released version.

Hi there 👋 thanks for the pull request!
We already have a branch which is currently being worked on, which should work with bevy 0.12 👍
https://github.com/BlackPhlox/bevy_dolly/tree/bevy_0.12
Regarding the patched version due to API ergonomics, the patching was made to use the transform of bevy instead of dolly's implementation, which removes the users' need for calling into_bevy_transform and vice versa.
Hope that makes sense :)

Do you run into this error when running cargo check/cargo build on your main branch @ActuallyHappening?
error[E0599]: no method named `iter` found for reference `&MoveAction` in the current scope
   --> src/helpers/pos_ctrl.rs:127:29
    |
127 | ... b) in v.iter().enumerate() {
    |             ^^^^ method not found in `&MoveAction`
    |
    = help: items from traits can only be used if the trait is implemented and in scope

I think my issue is caused by a change introduced in leafwing-input-manager v0.11, described here

InputMap::iter() now returns a simple iterator of (action, input) pairs

instead of InputMap::iter() returning (&PetitSet<UserInput, 16>, MoveAction), it now returns (&MoveAction, &Vec<UserInput>), with the order being swapped because breaking changes are fun : )

Would you be ok with changing the target branch tobevy

Sorry, my github on my phone glitched and closed the issue, would you be ok with changing the target branch to bevy_0.12 instead?

I don't really mind, whatever helps it to get published on crates.io. Or scrapped because the bevy_0.12 branch does everything better than my own changes.

I've updated the bevy_0.12 branch so LWIM now compiles and I've updated the .gitignore to not include the Cargo.lock and set you as a Co-author on the commit. I'll do my very best to see if I can deploy to crates.io today


Column name cells in crossfunctional tables can't be adjusted all at once in Confluence Cloud

Preflight Checklist

[x] I agree to follow the Code of Conduct that this project adheres to.
[x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe the bug
A couple of months ago, it was possible to adjust the height of single column title cells by dragging the orange diamond, but also change the height of all column header cell at once by using a keyboard shortcut. This option is not around anymore, I tried all of the common draw.io shortcuts but it doesn't work. Is the shortcut broken?
To Reproduce
Steps to reproduce the behavior:

Embedd crossfunctional table with at least two columns
Try to change column title cell 1 (see screenshot)
Hold down Cmd, Ctrl, Alt etc. to change all column title cells

Expected behavior
Using a shortcut to change the height of all title cells when adjusting one cell instead of changing the height for every single cell in a crossfunctional table.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context

Add any other context about the problem here.

Hi,
If you select cells in question and change Header size in Property/value does it help?

Hi,
If you select cells in question and change Header size in Property/value does it help?

Thanks for the report. This will be fixed in the next release.

Released in 21.1.2


chore: update forge remappings

For merging into #53 when done!

[x] OZ
[x] Chainlink
[x] PRBMath
[x] Permit bois
[ ] forge build gud (need to resolve this guy https://github.com/Bananapus/juice-contracts-v4/pull/54#issuecomment-1842111674, and then any other compilation issues outstanding)
[ ] do we need to update OZ, prb-math, and chainlink to latest versions in this PR? or save for separate PR for separation of concerns?

For merging into #53 when done!

getting weird error where lib/permit2's openzeppelin-contracts/contracts/utils/cryptography/draft-EIP712.sol import is mapping to lib/openzeppelin-contracts instead of lib/permit2/lib/openzeppelin-contracts

hacked a fix to the Uniswap permit2 remapping issue here https://github.com/Bananapus/juice-contracts-v4/pull/54/commits/5880ad9bde67ecb178fedf5d55abdb81e4508f59
figured out how to use prb-math without having to go through the npm package/being able to go direct to the Github here https://github.com/Bananapus/juice-contracts-v4/pull/54/commits/08b620d2b1233621aae9bc50ccb6701d14874a75


gpi_embed fails to dynamically load Python Library

While doing some testing with Anaconda3 v2.1.0 which runs python 3.4.1, I was seeing an error: "Failed to find python lib"
And a simulator error: "Unable to open lib libpython3.4.so (libpython3.4.so: cannot open shared object file: No such file or directory)"
I looked and sure enough there wasn't a library by that name, but there was one called libpython3.4m.so.
I dug into that issue a little bit more and that is a result of PEP3149 compliance with ABI Version Tagging support.
Rather than manually create PYTHON_DYN_LIB in the makefile, we should probably just be getting it from the sysconfig just like we do the version, library directory and the dynamic library directory.
The following seems to work for both Python2 and Python3:
PYTHON_DYN_LIB:=$(shell $PYTHON_BIN) -c 'from __future__ import print_function; from distutils import sysconfig; print(sysconfig.get_config_var("LDLIBRARY"))'
@chiggs and @stuarthodgson
While the above should fix this issue, I noticed the simulation ran just fine even with the error.  Given that we are linking to the library when we build gpi_embed, do we really need to be dynamically loading the python library?

@leftink the secondary loading is a result of #146 . And is done as simulators like to ship the kitchen sink with them rather than use system libs. We encountered an issue where the python loaded at run time was not the one used at link time. By compiling the version needed into the library and dlopening it we replace the lib with the correct one.

@stuarthodgson Sounds good.  I figured it was something like that.  The fix I have provided doesn't remove that, but only updates Makefiles to query the correct library name to load.


I am running a job,I want to open a new setting,but I cannot find folders in the ISO folder,what's wrong with my settings?

I am running in the Synology nas docker

Are you sure the USER_ID and GROUP_ID environment variables are properly configured to allow the container accessing the folder ?

my USER_ID and GROUP_ID are all "1000",should i chenge them to my account?

i run the code "id " on the docker ,returns that 0(root),like the imge below,should i chenge the two ID to "0"?

I'm not sure what you mean by "run on the docker", but tou should run the id command the host (Synology), not inside the container.
You can also check (on the host) which user owns you files and folders.  For example, you can run the command:
ls -l /volume1/MKVToolNix

i change the user_id and group_id to "0",it return to normal，then i check the folder permissions，it belongs to “root”，sorry for my low level error

ID 0 is root.  You may want to change ownership of the folder to avoid having to run MKVToolNix as root.

i am already change the ownershi ，thank you

mount the iso then restart the container, then you'll see the contents, Is not ideal but It works for me

Closing this issue.  Please re-open if needed.


Ways for pure JavaScript consumers to obtain type information from TypeScript libraries

@liamross brought up an interesting scenario in #115:

However, the fact that my documentation will have zero indication of the type of a parameter means that this could never serve as a replacement for JSDoc for me personally. If I write a library in TypeScript and it is consumed by a JavaScript application, I would like for there to be typings in the documentation, and not require that people are relying on IDE tooling or digging into the package to find types.
The first thing that drew me to this was the idea of it parsing types from the code to save the redundant declarations in the documentation.

If you build a library in TypeScript, the output includes declaration files (*.d.ts) that provide very accurate type information.  (Arguably the best in the world! :-) )  However many JavaScript tools perform static type analysis based on .js files, and ignore the .d.ts files.
These tools generally expect to obtain their type information from JSDoc tags such as this sample that I pulled from a random blog post:
    /** @namespace */
    var util = {
        /**
         * Repeat <tt>str</tt> several times.
         * @param {string} str The string to repeat.
         * @param {number} [times=1] How many times to repeat the string.
         * @returns {string}
         */
        repeat: function(str, times) {
            if (times === undefined || times < 1) {
                times = 1;
            }
            return new Array(times+1).join(str);
        }
    };

The TypeScript equivalent would look like this:
/** @namespace */
export namespace util {
  /**
   * Repeat <tt>str</tt> several times.
   * @param {string} str - The string to repeat.
   * @param {number} [times=1] - How many times to repeat the string.
   * @returns {string}
   */
  export function repeat(str: string, times: number = 1): string {
    if (times === undefined || times < 1) {
      times = 1;
    }
    return new Array(times + 1).join(str);
  }
}

The JSDoc annotations such as @namespace, {string}, [times=1] are redundant because we already expressed all those things using type declarations.  It would be annoying for developers to have to declare everything twice.  And it would be error-prone because TypeScript developers generally don't rely on the JSDoc tags themselves, so they won't notice mistakes.  (In my own anecdotal experience migrating code bases, I've found that these redundant tags are very frequently incorrect or inconsistent with the TypeScript types.)
The compiler does support JSDoc type annotations, so one possible idea would be for people to use JSDoc annotations instead of type declarations for the public parts of their API, since these annotations do end up in the emitted .js files.  However this would be limiting, since JSDoc's type expressions are quite limited compared to all the things you can express in TypeScript.  And it would be an awkward developer experience.
The "ideal" solution would be to improve the JavaScript tools to support .d.ts files when they consume a TypeScript library.  But let's assume that's impractical for various reasons.  What other approaches could we use, and can TSDoc help somehow?

One possibility would be a compiler feature (or plugin?) that emits JSDoc type annotations in the output .js files, based on the compiler's type analysis.  (I suspect this is closely related to another recent discussion, where people wanted the compiler to read plain .js files and generate .d.ts files based on its analysis.)
If the TypeScript source code has TSDoc comments, then in this approach the compiler would need to combine the TSDoc documentation with the type annotations to produce a JSDoc output.
It's tempting to expand the TSDoc language to optionally support every last JSDoc type annotation, and then the @microsoft/tsdoc library could be used to emit the JSDoc.   However I'm sure there already exist plenty of specialized libraries for generating JSDoc, which do that very well, and are focused around that scenario.  Keep in mind the goal is maximum compatibility with legacy JavaScript tools that are probably unable to adapt their parsers for this scenario.  So I wonder to what extent the TSDoc input really needs to be consistent with the emitted JSDoc output.
What do you think?  If someone has firsthand experience with this scenario, maybe they could provide some details.

Related: Microsoft/TypeScript#10

Hey thanks for extending this into an issue! Let me just elaborate a bit on what a dream scenario would be for me personally. Here's an example from the playground, but with typing included in the TypeScript. Note that as you mentioned above, ideally the typings would not be repeated in the actual documentation:
/**
 * Returns the average of two numbers.
 *
 * @remarks
 * This method is part of the {@link core-library#Statistics | Statistics subsystem}.
 *
 * @param x - The first input number
 * @param y - The second input number
 * @returns The arithmetic mean of `x` and `y`
 *
 * @beta
 */
function getAverage(x: number, y: number): number {
  return (x + y) / 2.0;
}

And here is an example of the documentation that said code would generate:

Summary
Returns the average of two numbers.
Parameters

Name
Type
Description

x
number
The first input number

y
number
The second input number

Return Value

Type
Description

number
The arithmetic mean of x and y

Remarks
This method is part of the Statistics subsystem.
Modifiers
@beta

What I'm not sure about is whether that would be unreasonably difficult to implement, or whether that is even a requirement / goal of this project.

@liamross Hrmmm...  I'm a little confused by your latest comment.  What would the expected output look like for the .js files?
I'm reachable on Gitter if you want to chat directly.

We chatted about this. @liamross clarified that for now he's mainly interested in generating web site documentation.  I suggested to take at API Extractor or TypeDoc, both of which are complete documentation tools (whereas @microsoft/tsdoc is just the parser).  They use the TypeScript compiler engine to crawl your library's API, and then generate a documentation web site based on your doc comments.  API Extractor 6 has already integrated the TSDoc parser.


help enable source link for FsCheck

https://twitter.com/kurt2001/status/900255652517466113
https://github.com/fscheck/FsCheck/issues/377

https://github.com/fscheck/FsCheck/pull/378

Pull request was merged, but later reverted, citing problems with debugging F# with the portable pdb format.


[Lark] Fix read properties of undefined

Description

Fix read properties of undefined (ref)
Update the logo to SVG format

Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

Hi @tmkx 👋
SVG for extension and command icons is not possible yet, could you revert to PNG?
Please also add a CHANGELOG entry


doc(README): remove typo

Description:
This Pull Request fixes a typographical error in the README.md file.
Changes Made:

Corrected "tranform" to "transform" in the README.md file.

Additional Information:
This fix is not related to any existing issue. It's a minor typo that I noticed while reviewing the README.
Thank you for considering this contribution.

thank you! nice catch!


Assigning a class to a property with signature '(): any' results in a compiler error

TypeScript Version:  1.8.7
Code
interface Foo {
    (): any;
}

class Bar {
    constructor() {
        console.log("Bar");
    }
}

function Baz() {
    console.log("Baz");
}

var Bat = (function () {
    function Bat() {
        console.log("Bat");
    }
    return Bat;
}());

const foo1: Foo = new Bar();
const foo2: Foo = new Baz();
const foo3: Foo = new Bat();

var Bar = (function () {
    function Bar() {
        console.log("Bar");
    }
    return Bar;
}());
function Baz() {
    console.log("Baz");
}
var Bat = (function () {
    function Bat() {
        console.log("Bat");
    }
    return Bat;
}());
var foo1 = new Bar();
var foo2 = new Baz();
var foo3 = new Bat();

Expected behavior:
No error when assigning new Bar() to foo1, because in the emitted JavaScript, Bar and Bat are identical in how they work. Bar and Baz are also similar.
Actual behavior:
The following compiler error is displayed:

Type 'Bar' is not assignable to type 'Foo'.
Type 'Bar' provides no match for the signature '(): any'
const foo1: Foo

Context:
The definition file for Knockout has this (source):
    interface Config {
        viewModel?: ViewModelFunction | ViewModelSharedInstance | ViewModelFactoryFunction | AMDModule;
        template: string | Node[]| DocumentFragment | TemplateElement | AMDModule;
        synchronous?: boolean;
    }

    interface ViewModelFunction {
        (params?: any): any;
    }

Creating a component like this works fine, but displays a compiler error:
class ViewModel {
    // ...
}

export const MyComponent = {
    viewModel: ViewModel,
    template: require("./MyComponent.html"),
}

No error when assigning new Bar() to foo1

I don't understand your assertion. It's clearly not legal to invoke an instance of Bar as if it were a function. It fails at runtime. If you tried to use new Bar() as the foo1 contract indicates - by invoking it - it would not work.

It fails at runtime.

It doesn't. If I run the code on https://www.typescriptlang.org/play/ I see this in the browser console:
Bar
Baz
Bat

It doesn't.

It does. You said this:
interface Foo {
    (): any;
}

This means "Foo can be invoked as a function". In other words, your declaration of Foo implies that this is legal:
const x: Foo = ...;
x();

If you had written this code, which attempts to use that definition that you just wrote, you would get an error
const foo1: Foo = new Bar();
foo1();

My apologies, it seems I made some errors in setting up a minimal example, it doesn't properly reflect the real code. I'll close this for now and I'll try to go over it again later.


_search with wildchar

After the version 0.34.  I am not able to use the wildchar in the _search option( or the full text search). It will not return any result unless I specify the whole word for text search.
If I use 'match :search || "*" ' in the sql statement then it will work as expected.

I'm afraid this is by design: supporting wildcards in that mode was more-or-less accidental and often resulted in unexpected user-facing syntax errors when users accidentally entered search text that included characters with special meaning to SQLite.
You can still execute wildcard searches but you have to do so using custom SQL statements.
I'm open to suggestions for more friendly ways to support this functionality. Would an alternative _search_wildcard= URL parameter be worth supporting I wonder? What's your specific use-case for wildcards?

Thanks Simon,
My use case is using Datasette for full text search type ahead.  That was working pretty well. The _search_wildcard= option will be awesome.  Thanks

I'm going to call it ?_search_raw= because it will pass through the value as a raw (unprocessed) argument to SQLite FTS, which means it will expose features other than just wildcards: https://www.sqlite.org/fts5.html#full_text_query_syntax

?_search_raw= doesn't work because it clashes with an existing feature - you can use ?_search_colname= to search just within a specific column, and there could possibly be a column called raw.
I could go with ?_searchraw= - or maybe have an additional "mode" selection like ?_search=foo*&_searchmode=raw

Nice thing about the "mode" concept is that I can optionally reflect it in the HTML UI in some way - maybe with a checkbox for "raw" mode that only shows up if the user hits the page with ?_searchmode=raw in the querystring.

You can try this right now like so:
pip install https://github.com/simonw/datasette/archive/search-raw.zip

Then use the following:
?_search=foo*&_searchmode=raw`

Still needs documentation before I can land it in master.

Awesome, thank you so much.
On Sun, Feb 23, 2020 at 1:44 PM Simon Willison<EMAIL_ADDRESS>wrote:

You can try this right now like so:
pip install https://github.com/simonw/datasette/archive/search-raw.zip
Then use the following:
?_search=foo*&_searchmode=raw`
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/simonw/datasette/issues/676?email_source=notifications&email_token=AN3FXEFS6B22U2NOT6M5FULRELNY7A5CNFSM4KYIOIB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWGYTI#issuecomment-590113869,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AN3FXEANDJ6AIHGU4ADK4D3RELNY7ANCNFSM4KYIOIBQ
.

OK, this is in master now. You can install master using:
pip install https://github.com/simonw/datasette/archive/master.zip

Documentation here: https://datasette.readthedocs.io/en/latest/json_api.html#special-table-arguments


Hot module replacement?

So I'm going to start with the the premise that Hot Module Replacement™ should be as easy and pluggable as https://github.com/substack/react-starter-hmr, with minimal change to the client application.

This is a rough-guide on what is required to get it set up:

Install the dependencies: npm i --save-dev browserify-hmr ud
Add the plugin to the browserify/watchify bundler watchify client.js -p browserify-hmr ...
Add the ud.defn(...) annotation to the part of the application to show which bits of the program are suitable for hot-reload (per screenshot above)
Watch view updates appear insta-matically in the page without losing state

My trouble is that with step 4. I couldn't find a way with choo to force a re-render of the page's current state like in the React example. I got close in two different ways - forcing a reboot of the entire app (so reverting to initial state) or views updating the next time they were rendered (not insta-matically).
If anyone knows the secret to getting this set up, please tell! Otherwise if a change is required in choo to facilitate this, let's figure it out? I think it's going to be something like exposing a way to call render/re-render, unless I'm missing something!

Something magic (read: something I haven't figured out yet 😁 ) causes the React example to re-render, even though it seems to just be updating the class/prototype of the <App /> component.
@timwis I'm going to give your suggestion of a noop-y reducer a try and see if that sorts us out!

Ok, brace yo'selves… here's how HMR is achievable in choo right now:

npm install --save-dev browserify-hmr ud
add -p browserify-hmr to the browserifyoptions
every "route" (i.e every view that you provide to the router) must be wrapped in the ud.defn() call like so:

ud.defn(module, (state, prev, send) => {
  return html`

Blah

  `
})

(here's the nastiest bit!)

define a noop reducer and a subscription that repeatedly calls it:

  ...
  reducers: {
    noop: (action, state) => ({})
  },
  subscriptions: [
    (send, done) => {
      setInterval(() => send('noop', done), 1000)
    }
  ]
  ...

So I'm going to try to distill all of this down to what I think are the two functional requirements needed to get a decent dev set up…

allow the user to hook into choo's render and wrap it, which will become the single place ud.defn(...) needs to be added to the codebase
provide a way to trigger a render independent of state changes

The final piece of the puzzle is knowing when to call 2.. I'm still baffled by how the React one works. Does React use a render/digest loop? As far as I can see, browserify-hmr nor ud provide "events", but I'm sure we could hook into them somehow. The former logs a message to the console when it hot-swaps a module in.

Noting down @yoshuawuyts hot reload proof of concept here https://github.com/yoshuawuyts/hot-app-replacement/tree/choo
I think this is interesting but as far as I can see it

saves app state
reloads the entire bundle
loads app state
re-boots the entire app

?
I think it would be cool if we could leverage these community projects and also benefit from actual hot-swaps of updated modules, rather than sending the entire bundle. I can see the benefit of the entire reload, if any views have any state that's not stored in a model obviously this would help.

I'd favor the approach in hot-app-replacement because:

it's simpler to maintain - browserify-hmr has proven to be buggy, and
I've found it complicated to debug
it's simpler to reason about - people can jump in and write their own
implementations / contribute
with choo apps it's an anti-pattern to have state live outside choo;
should probably write a bit more in depth
about this, but some widgets aside (hey maps) all state should merrily be
handled by choo for transparancy
watchify performs incremental rebuilds; the cost of then sending the
full bundle over the loopback interface is negligable
using the approach in hot-app-replacement also works for CSS, removing
the need for some different CSS solution

Hah yeah so that's about it - obviously you're free to do what you want,
but this is my take on it (:
On Wed, Oct 26, 2016 at 6:59 PM Ben Gourley<EMAIL_ADDRESS>wrote:

Noting down @yoshuawuyts https://github.com/yoshuawuyts hot reload
proof of concept here
https://github.com/yoshuawuyts/hot-app-replacement/tree/choo
I think this is interesting but as far as I can see it

saves app state
reloads the entire bundle
loads app state
re-boots the entire app

?
I think it would be cool if we could leverage these community projects and
also benefit from actual hot-swaps of updated modules, rather than sending
the entire bundle. I can see the benefit of the entire reload, if any views
have any state that's not stored in a model obviously this would help.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yoshuawuyts/choo/issues/295#issuecomment-256412122,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlevJdm_Fim_PYDb7PCOyMZA_EJYznks5q34bUgaJpZM4KhBw_
.

@yoshuawuyts ok you have me convinced! Can we put together a list of todos in order to have this packaged up and ready to go?
I guess the only one reliant on you is the merge/publish of new barracks version? I'm happy to work on some of the other bits if we define what they are.

@bengourley

[ ] create a lil plugin that can be loaded into choo (choo-hmr perhaps?)
[ ] find a good Server Sent Events (SSE) implementation to send the bundles through; websockets usually requires compiling native code which is not great
[ ] patch bankai to use the server implementation

Something like this?

Sounds good @yoshuawuyts :D I might be able to get started on choo-mhr this week. It's going to be super useful to me on a project I'm working on.

So I've come up with a solution! Anyone want to try this out?
npm i --save choo-resume hot-rld

const app = require('choo')()
const resume = require('choo-resume')

@bengourley oohhhh really digging this; might just work on top of this from https://github.com/yoshuawuyts/bankai/pull/86 - use the same client, but use bankai as the server. :grin:
Is there a way we could make this also work for CSS ? perhaps have different push channels that set the script and css individually? If we document the wire protocol then we could have compatible client and servers and like be super happy with all of it :sparkles:

@yoshuawuyts I decoupled the cli/standalone server from the sse route handler, so if you pull in require('hot-rld/server') you get a fn with signature (req, res) => {} which you can mount wherever you like on a pre-existing server. You then just need to provide the address argument to the client script generator client('http://myhost:1234/path-to-where-sse-was-mounted')
As far as CSS is concerned, yeah sure we could namespace the sse events into channels. FYI I don't know if you dug deep into the code, but I'm only sending tiny payloads (i.e. the path of the file that needs replacing, not the source of the bundle) and the browser is re-requesting the entire bundle from wherever it was served initially.

I've published v1 of both https://github.com/bengourley/choo-resume and https://github.com/bengourley/hot-rld.
@yoshuawuyts hot-rld now supports css too.

Module reloading is part of bankai now too, couple with https://github.com/yoshuawuyts/choo-reload for SSE based reloading :sparkles: