simplify extends for the account class

[0xknwn]

Motivation and Resolution

I am working with Starknet abstract account. To support our work, I am extending the starknet.js Account class to add some additional behaviours on the application side. I am not changing the way the transaction version is used internally and would still need to implement the account deployment.

You have defined 3 private methods in the class which makes sense to not expose to the outside. However in the context of extending that class we would prefer to access those 3 methods instead of rewriting them. Obviously, this is your decision to make. For that particular scenario, I think having those 3 private methods turned into protected makes more sense.

RPC version (if applicable)

• not applicable

Usage related changes

• It will not affect any user that is not extending the account class (i.e. most developers)
• It will simplify the ability to extend the Account

Development related changes

• We did not add any test as the protected functions can still not be accessed from the outside and the code can easily be copied/pasted into a new private function anyway.
• If you think something should be done to enhanced my request, let me know.

Checklist:

• Performed a self-review of the code
• Rebased to the last commit of the target branch (or merged it into my branch)
• Linked the issues which this PR resolves
• Documented the changes in code (API docs will be generated automatically)
• Updated the tests
• All tests are passing

[tabaktoni]

LGTM!

[tabaktoni]

If you can please do share an example of your AA implementation it could be a valuable resource for others.

[0xknwn]

If you can please do share an example of your AA implementation it could be a valuable resource for others.

I will for sure! Both the Cairo and the Starknet.js implementation. I just need some time to get it clean

Also thank to the 2 of you @tabaktoni and @ivpavici for this lightning merge!

[github-actions]

🎉 This PR is included in version 6.6.0 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[0xknwn]

🎉 This PR is included in version 6.6.0 🎉

Actually, no it is not. Can you double-check? It could be because of the error in the CI. Thank you

[ivpavici]

🎉 This PR is included in version 6.6.0 🎉

Actually, no it is not. Can you double-check? It could be because of the error in the CI. Thank you

yeah the github-actions post here is wrong, it will be included in the next version! 🙏
@penovicp can you check please when you find some time?

[penovicp]

The notification does look like a bug. My guess is that it might stem from an overlap arising from the next-version branch name, that when identifying PRs to notify the plugin expands the set with PRs that have been merged into branches that have themselves been merged into the configured release branch without or with faulty verification of the included commits. Essentially my presumption is the following sequence: next-version merged to develop; this PR merged to next-version; manual release; faulty notification for all merges into next-version and not just from the first step.

I haven't found an existing corresponding issue and would need to do a deep dive into the release plugin code to corroborate my assumption.

[github-actions]

🎉 This issue has been resolved in version 7.0.0 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀