feat: use interfaces from reference implementation and bump version

[jaypaik]

Removing the 6900 interfaces from this lib in favor of using the interfaces from https://github.com/erc6900/reference-implementation.

BasePlugin has also been deleted. We should use BaseModule from the reference implementation.

Also renaming this package to @erc6900/modular-account-libs (from modular-account-libs)

[jaypaik]

Hmm, I should update this to use PackedUserOperation. Update incoming.

[jaypaik]

@adamegyed why did we remove the explicit dependency on the 4337 ref impl again here: db6c47f ?

[adamegyed]

We should re-copy this from the RI, because it's missing some parts like the byte layout diagram, and contains old fields like _PRE_HOOK_ALWAYS_DENY.

[jaypaik]

Woops, good catch.

[jaypaik]

Wait, I did copy this from the reference implementation 😂 . So I guess that needs to be cleaned up?

[adamegyed]

oof, yeah we should clean that up. will get on it...

[adamegyed]

erc6900/reference-implementation#183

[adamegyed]

why did we remove the explicit dependency on the 4337 ref impl again here: db6c47f ?

When this repo gets added as a dependency to another repo, it may be added either as a git submodule (foundry) or as an NPM package. If this repo depends on any external imports, those imports are not necessarily going to be available to the user unless this repo uses the same import scheme as the user. Because the user may pick either of the two, this repo should have no dependencies, except those which are needed in tests.

[adamegyed]

Also renaming this package to @erc6900/modular-account-libs (from modular-account-libs)

Could you verify that this still works with the github: form of adding NPM imports? I thought there was some dependency between the name in package.json and the name used in the dependency statement.

[jaypaik]

Also renaming this package to @erc6900/modular-account-libs (from modular-account-libs)

Could you verify that this still works with the github: form of adding NPM imports? I thought there was some dependency between the name in package.json and the name used in the dependency statement.

Yes this works! Already using this line in package.json (after erc6900/reference-implementation#181):

"@erc6900/reference-implementation": "github:erc6900/reference-implementation#v0.8.0-rc.1",

Will just need to update modular-account's package.json later.

[jaypaik]

When this repo gets added as a dependency to another repo, it may be added either as a git submodule (foundry) or as an NPM package. If this repo depends on any external imports, those imports are not necessarily going to be available to the user unless this repo uses the same import scheme as the user. Because the user may pick either of the two, this repo should have no dependencies, except those which are needed in tests.

We should expect the repo importing this package to import https://github.com/eth-infinitism/account-abstraction for those interfaces, right? Why would we expect them to use the interfaces that we provide here?

[adamegyed]

We should expect the repo importing this package to import https://github.com/eth-infinitism/account-abstraction for those interfaces, right? Why would we expect them to use the interfaces that we provide here?

The previous state of this repo didn't have that dependency. The downside with requiring users to also install separate dependencies is that they must map things in the same way as this repo's code does. So for instance, this PR uses imports from "@erc6900/reference-implementation/...". If the user imports the RI but maps it differently, then this won't work, and they'll have to either map it twice, or change all of their code's mappings. Having no dependencies was my attempt at resolving this issue.

[jaypaik]

We should expect the repo importing this package to import https://github.com/eth-infinitism/account-abstraction for those interfaces, right? Why would we expect them to use the interfaces that we provide here?

The previous state of this repo didn't have that dependency. The downside with requiring users to also install separate dependencies is that they must map things in the same way as this repo's code does. So for instance, this PR uses imports from "@erc6900/reference-implementation/...". If the user imports the RI but maps it differently, then this won't work, and they'll have to either map it twice, or change all of their code's mappings. Having no dependencies was my attempt at resolving this issue.

Oof. Solidity dependencies really need better tooling. I imagine this is fine if importing as an npm package but causes problems when used as a submodule?

[adamegyed]

I think it's equally a problem between the two different forms. But thinking a bit more about this, maybe we're ok with making it a requirement for users of this library to also install additional dependencies, and handle remappings. We should just call it out in the README.