Narrow type of provider argument

[mcmire]

Previously, the provider could be any kind of object. Now, it must be an instance of SafeEventEmitterProvider. This allows us to replace Web3Provider with @metamask/eth-query in a future PR (see #58).

[socket-security]

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Issue	Package	Version	Note	Source
Bin script confusion	@ethereumjs/rlp	4.0.1	Bin Script: rlp	@metamask/eth-json-rpc-provider@2.3.0 via package.json
Bin script confusion	rlp	2.2.7	Bin Script: rlp	ethereumjs-util@6.2.1 via package.json

Next steps

What is bin script confusion?

This package has multiple bin scripts with the same name. This can cause non-deterministic behavior when installing or could be a sign of a supply chain attack

Consider removing one of the conflicting packages. Packages should only export bin scripts with their name

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of package-name@version specifiers. e.g. @SocketSecurity ignore foo@1.0.0 bar@* or ignore all packages with @SocketSecurity ignore-all

• @SocketSecurity ignore @ethereumjs/rlp@4.0.1
• @SocketSecurity ignore rlp@2.2.7

[mcmire]

Bin script confusion makes sense.

[legobeat]

Would it be viable to have this type broken out to a separate package, if not either inlined or in .d.ts file here? Looking at the lockfile diff, it's quite a lot of transitive dependencies pulled in for a single type-declaration, which won't even be present at runtime...

[legobeat]

Just had this thought which may or may not be relevant here: what if type-only imports went back to devDependencies, but with the addition of a build/bundle-step which ensures that any types used by them are included in published packages in d.ts declarations?

[Mrtenz]

Is there an easy way to do that?

[mcmire]

Ah sorry I didn't see this comment before.

Because @metamask/eth-json-rpc-provider shows up in the type declaration, it can't be in devDependencies, it has to be in dependencies instead. This ensures that TypeScript consumers automatically get the type definitions for this import and do not have to add it themselves.

I know that we've discussed splitting this type off before. I am not opposed to that, I am just unsure where. Also, I suspect that most of these transitive dependencies are coming from @metamask/utils. I will open a discussion in chat for this since I feel like it might be easier to talk there.