Support crate renames in macro expansions

[uint]

Currently, the near-sdk crate is hardcoded into macro expansions.

The problem with that is users may wish to rename the near-sdk crate, unexpectedly breaking all macros.

It should at the very least be possible to customize the crate name in expanded code using an attribute like e.g. #[near_bindgen(crate = "near-sdk-alt)].

Something even better could also be investigated: rust-lang/futures-rs#2099

[ruseinov]

Will take this on in the near future.

[Gerson2102]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I'm a junior software developer from the Dojo Coding community with contributions to several OnlyDust projects. Including Madara, Cairo native, kakarot-rpc, and Giza. All the projects where I contributed are in Rust, so I have been dealing with this language for a while. You can check my OD profile here: https://app.onlydust.com/u/Gerson2102

How I plan on tackling this issue

I will start by seeing the code base. Understanding what i have to do. Checking the resources that is shared with me. If I'm too stuck in this, I will look for assistance on the telegram group.

[PrincesoDan]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

i'm developer

[Dev-AndresGR]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I have a dfan background in Rust development, particularly with macros and crate management. In previous projects, I’ve worked extensively with macro expansions and crate configuration, which has given me a deep understanding of how Rust macros interact with crate names and paths. For example, I’ve customized macro expansions to support different crate names and paths, ensuring that they adapt to various project structures without breaking functionality. This experience allows me to effectively address the issue of hardcoded crate names in the near-sdk macros and implement a solution that supports customizable crate names.

How I plan on tackling this issue

To address the issue of hardcoded crate names in macro expansions, I would take the following approach:

Investigate the Current Implementation: Start by examining the current macro expansions in the near-sdk crate to understand how the crate name is being hardcoded. This involves looking at how the macros are defined and where the crate name is referenced.

Implement Customization Support: Modify the macros to support customizable crate names by introducing an attribute like #[near_bindgen(crate = "near-sdk-alt")]. This attribute would allow users to specify an alternative crate name, which would be used in the macro expansions. I would update the macro definitions to handle this attribute and replace the hardcoded crate names with the value specified in the attribute.

Explore Advanced Solutions: Based on the insights from the linked GitHub issue (futures-rs#2099), I would investigate more advanced solutions if applicable. This could involve leveraging new Rust features or patterns that allow for more flexible crate naming in macro expansions.

Testing and Validation: Ensure that the changes are thoroughly tested to verify that macros work correctly with different crate names. This includes updating existing tests and writing new ones to cover various scenarios where crate names might be customized.

Documentation and Examples: Update the documentation to reflect the new capability and provide examples of how to use the customizable crate name feature. This helps users understand and adopt the changes effectively.

By following this approach, I aim to make the near-sdk macros more flexible and user-friendly, accommodating different crate names without causing unexpected issues.

[Ifechukwudaniel]

Should this not be closed

[genamol]

Is it okay if I tackle this?

[Shaarps]

Can I attempt this issue?

[g4titanx]

Can I take this from here?