Summary

Make evmts typesafe via adding a custom ts plugin

Why

For evmts to be production ready it must be typesafe. By default, typescript has no way of infering types from solidity files. What we need to do is create a tsplugin that creates a pipe

solidity-import -> abi -> abitype -> final types

This will allow typesafety in the editor without a build step which is the ultimate ux for making solidity a first class citizen in js.

Future plans

For this iteration we are only offering ts support in editors. The actual typescript build will not fail. Adding a special check that users can use instead of tsc (similar to what astro does) will be one of the first priorities after MVP is love.

In the future we want to expand this to full ts-language server support so we can improve developer experience within the editor and create a full-blown framework around it similar to astro

What

1. document how to use the ts plugin in the tsconfig
2. Utilize fixtures as manual tests for now. Since the actual implementation of this is unknown it's hard to write unit tests up front
3. Implement the plugin such that it infers the abi
4. Pipe that through abi type to figure out the contract types

How

Docs

Documentation should be added to a typescript section in the docs. It should be pretty brief

Fixtures

Set up any additional fixtures if necessary

Infer abi

Deliverable here is to extract the abi type from a solidity file location based on compiling the contract under the hood. Check early to make sure async nature of that isn't going to cause problems

Pipe through abi type

Once we have the abi we can use abitype to infer contract types. Consider just reusing viem contract types more or less for now. We can modify it later if necessary

package

Should live in @evmts/tsplugin

• Docs should use astro docusourus or something
• SHould be generated if possible
• Should have good .md support
• Should have working code examples

POC 1 still doesn't work. Debug why.

Add a pnpm link to lib/ethereum-js so we can modify it

Summary

Implement rollup plugin via reusing the foundry and hardhat plugins from wagmi. The plugin should just reuse wagmi cli plugin interface under the hood for it's plugin interface but otherwise function exactly like the current POC version of the plugin works

Why

We need to generalize the plugin. The POC works great but it is hardcoded to Forge with minimal configuration. We can easily and quickly add configuration via reusing wagmis code for their cli.

EVMts believes in being modular and we want the plugin to work with other runtime tools such as Viem and Ethers. This will help the plugin establish itself as a standardized industry build tool like jsx rather than a one off tool.

The ability to use solidity code in typescript as a first class citizen like graphql files or css files creates a more streamlined experience for evmts but other libraries such as ethers, viem, or wagmi can utilize this build tool in the same way.

Future plans

• get to 100% reuse wagmis code
• Easy path to adding etherscan ect. support later such that devs can import directly from etherscan
• First class support for wagmi/viem hooks later as well

What

1. Document how to use the plugin
2. Add fixtures and tests for both hardhat and forge
3. Write tests
4. Create a wrapper around wagmi plugin to use within evmts plugin

How

Docs

Plugin usage should be documented. For now leave out the detail that these are wagmi plugins (even if we are rexporting wagmi plugins. Protect the API from breaking on latest anytime wagmi plugins change their interface.

Testing

Fixtures should be testing this with both the hardhat plugin and the foundry plugin

Implementation

wagmi plugins return an object that includes the abi, address(if known), and contract name

our prototype plugin [returns a very similar object](https://github.com/evmts/evmts-monorepo/blob/main/packages/plugin-internal/src/getArtifacts.ts)

The implementations are as follows in order of preference

Option 1: Add bytecode to returned object in wagmi plugin

Add bytecode to wagmi plugin as an optional property build tools can choose to use

Option 2: Create a new plugin

Just create a new plugin that extends the wagmi plugin interface to also include bytecode

Use bytecode in plugin

Now swap out the current unconfigurable forge logic in @evmts/plugin for wagmi plugin

Add plugin options to rollup plugin

Accept the wagmi plugin interface as an options. Default to attempting to use an unconfigured forge plugin

Reuse code from the rollup plugin in teh webpack plugin

The jest test is serving as an e2e test for now
Add an e2e test with playwright too in app/e2e

Summary

Ticket is placeholder for all the tickets needed to implement forge cheat codes and evm execution via reth+foundry to wasm.

needs more investigation to demystify the work needed to be done

Why

The POC uses ethereumjs and while ethereumjs was by far the easiest way to get to an MVP, it was clear it would not scale to ever being production ready and maintainable without significant work. Comparatively, if we can compile foundry and reth to wasm with minimal hacks and changes, we can have production ready tooling that maximally reuses existing implementations of the API we are going for especially forge cheat codes

What

• Attempt a POC using wasm to implement a foundry cheat code to demystify the work needed here
• break it up into smaller tickets

How

• Search for someone who is already doing this
• Hack on it until the path forward is clear

Summary

Add developer docs

Why

We want contributions

What

• Create developer doc one pager in the vuepress docs
• link to it in the contributing.md
• polish contributing.md

How

• create a diagram of how the runtime works
• create a diagram of how the build works
• create docs about how to create a plugin
• keep any repo specific docs like how to set up repo in the github repo off the docs

• Add a bin so that new projects can be created
• Make it a little more feature rich

For speed, stability, and the ultimate developer experience 🤠

If the signer is not connected to the correct chain a request to switch chains should be issued

It's possible we can just get away with a babel plugin and not bother with rollup/webpack

• SHould have a decentralized indexer
• Should have a light client of some flavor
• Should verify all state and execute the evm clientside
• Should plug into the OP stack

• should be able to read strings
• should be able to read numbers
• no other cheat codes necessary

Should be able to pass in type. Doesn't need to be typesafe fully yet just make user give a type and maybe add a one off cli tool to check for it.

Currently using rollup plugin as vite plugin since it works but we might be able to get better peformance by making a vite plugin

Should be able to simulate a tx and return information such as events emitted and gas used

Pnpm fetch is a less hacky way of efficiently building a dockerbuild. Currently we have a hacky multistage build that copys in package.json. Pnpm fetch will read only pnpm.lock

Summary

Create a demo on something like stackblitz that allows devs to play with evmts

Why

An online demo will create the lowest friction way for devs to see how easy to use evmts is

What

• Implement a demo on stackblitz
• Link to it in readme
• Link to it on docs site

How

Stackblitz or whatever works

Add basic rollup plugin similar to the babel plugin

Summary

Add an example repo that deploys to vercel

Why

Forge is not on npm and they have no plans to enable it. It is likely a big lift until the moment forge is packaged up as a single binary.

We need to either find some hack or offer an easy to use example to make it easy for anybody to deploy to vercel

What

• create an example repo that is deployed to vercel
• link it in docs

How

No idea figure it out. Easiest option is to build within a docker container. We need to attempt to find something easier than that though.

Should be similar to the foundry examples folder

Summary

Implement fixture projects with playwright tests building them and running e2e tests vs them

Why

We are following documentation and test driven development. After first pass of docs are done we should be good to implement fixtures. We should then iterate until the first draft of the API looks clean. This will guarantee we don't make the mistake of making the implementation easier at the cost of the library api being worse

What

• Add a bunch more examples to the existing @evmts/playground fixture
• Modify the existing e2e test to the new api
• Add test cases to cover all functionality in documentation (skip things that should be unit tests)

How

• follow existing examples

Should use the app registry contract

Save local state to op stack analogous to using firebase