metamask / json-rpc-engine Goto Github PK

Tasks

• Transfer open issues from the source repo into the core monorepo using the Transfer issue feature.
  • If applicable, rename to include package name to provide better context when encountered in the core monorepo.
• For open PRs in the source repo, lock conversation (with no reason provided), and leave a comment requesting that authors reopen the PR in core with a link pointing to the discussion in the original PR.

This library has now been migrated into the [core monorepo](https://github.com/metamask/core/). This PR has been locked and this repo will be archived shortly. Going forward, releases of this library will only include changes made in the core repo.
- Please push this branch to core and open a new PR there.
- Optionally, add a link pointing to the discussion in this PR to provide context.

• Leave a note in the source repo's README announcing the migration and pointing to core.
  • #182

<table><tr><td><p align="center"><b>⚠️ PLEASE READ ⚠️</b></p><p align="center">This package has been migrated to our <a href="https://github.com/MetaMask/core"><code>core</code></a> monorepo, and this repository has been archived. Please note that all future development and feature releases will take place in the <a href="https://github.com/MetaMask/core"><code>core</code></a> repository.</p></td></tr></table>

• Archive the source repo to prevent any changes from being pushed to it going forward.

References

• See #1551 (comment) for context on the migration process.
• See #1079 (comment) for context on the migration initiative.

async function getCode(req, res, next) {
    // do something
    await next();
    if (res && res.error) {
        res.error = null;
        res.result = "0x";
    }
  }

The upper middleware still can see the res.error object

"dependencies" currently contains "babel-preset-env" and "babelify"

afaik, they are used only during build, and thus can be moved into devDependency, and not clutter the client's tree.

Maybe we just say "if no callback is provided to handle, return a promise".

Would there be any objection to this?

Hello,

I'm using json-rpc-engine from a create-react-app, and when building an production minified JS bundle (npm run build), I get an error:

Creating an optimized production build...
Failed to compile.

Failed to minify the code from this file: 

 	./node_modules/json-rpc-engine/src/index.js:5 

Read more here: http://bit.ly/2tRViJ9

which says :

Some third-party packages don't compile their code to ES5 before publishing to npm. This often causes problems in the ecosystem because neither browsers (except for most modern versions) nor some tools currently support all ES6 features. We recommend to publish code on npm as ES5 at least for a few more years.

It would be nice to publish a ES5 compiled version of json-rpc-engine (issue related in metamask/mascara)

Many thanks!

I wanted to use this repository but I do not see a license. Can you please add a license file?

@metamask/utils now houses most of the types from this package (JsonRpcRequest, JsonRpcResponse, and the like). The only thing that we haven't brought over yet is PendingJsonRpcResponse (this issue is tracked in MetaMask/utils#39). Once this is moved over, we can remove the types from this package and import them from @metamask/utils.

When middleware sets an error object on the response, the error does not show up in the error-first completion handler

CircleCI should be enabled for this project

The following "dependencies" should be reclassified as "devDependencies", as they are causing errors in upstream packages.

"@babel/preset-env": "^7.3.4"
"babelify": "^10.0.0"

Error example: ... json-rpc-engine > @babel/preset-env > @babel/[email protected]" has unmet peer dependency "@babel/core@^7.0.0-0".

Originally posted by @Qqwy at MetaMask/metamask-extension#4693:

Expected Behaviour

The call

web3.currentProvider.sendAsync({id: 1, method: "does_not_exist", params: []}, console.log)

returns

{
  "id": 1,
  "error": {
    "code": -32601,
    "message": "JSON-RPC method not found"
  }
}

(obviously, the actual content string of the message field is not specified by the standard, but something akin to this would probably be the most understandable)

Actual Behaviour

This call returns

{
  "id": 1,
  "error": {
    "code": -32603,
    "message": "Internal JSON-RPC error."
  }
}

This means that MetaMask (or possibly one of its dependencies) does not properly follow the JSON-RPC Spec.

Browser+OS used

This is using MetaMask version 4.8.0 on FireFox on Manjaro Linux, but I doubt this problem is stack-specific.

It seems that npm releases aren't generating a build. After a fresh npm install my directory (node_modules/json-rpc-engine) doesn't contain a build or lib as per the documentation.

node_modules/json-rpc-engine
├── CHANGELOG.md
├── README.md
├── package.json
├── src
│   ├── asMiddleware.js
│   ├── createAsyncMiddleware.js
│   ├── createScaffoldMiddleware.js
│   ├── getUniqueId.js
│   ├── idRemapMiddleware.js
│   ├── index.d.ts
│   ├── index.js
│   └── mergeMiddleware.js
└── test
    ├── asMiddleware.spec.js
    ├── basic.spec.js
    ├── createAsyncMiddleware.spec.js
    ├── idRemapMiddleware.spec.js
    └── mergeMiddleware.spec.js

Refs MetaMask/safe-event-emitter#1 and MetaMask/rpc-errors#7

As the two dependencies of the project are migrated this project is next in line for a TS migration.

We should export type guard functions for narrowing JsonRpcResponse to the success or error subtypes, a problem that comes up every time await engine.handle() is called.

I'm learning the principles of metamask, and I don't understand several of the libraries, and I can't find the corresponding documentation.

The project should be migrated to use Yarn:

• for consistency with the rest of the org's packages
• for less client bugs
• for a more humane lockfile format

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organiszation’s settings page, under Installed GitHub Apps.