chore(roadmap-v1): welcome on sprout 🌱

[42atomys]

Migrating to Sprout 🌱

Introduction

Welcome to the roadmap for our ambitious project: Evolve Sprig to Sprout. This project is inspired by the core ideas of Sprig, a Go template function library known for its robustness and ease of use. Our mission with Sprout is to take the foundation that Sprig has laid down and evolve it further, addressing some of the challenges and limitations we've identified. Our ultimate goal is to create a more streamlined, efficient, and user-friendly template function framework that can cater to a broader range of use cases without compromising on performance and flexibility.

Important

The organisation @go-sprout have receive the project.

Key Objectives

Below are the specific objectives we aim to achieve with the Sprout project:

1. Minimize Dependencies

Reduce the number of external dependencies to mitigate frequent update cycles, making Sprout more stable and lightweight.

2. Enhanced Documentation

Provide comprehensive, easy-to-understand documentation that covers all functionalities, use cases, and examples to improve the developer experience.

Tip

This convention are defined and writed to available here: Official documentation

3. Conventional Function Naming

Establish clear, consistent naming conventions for functions to enhance code readability and maintainability. Unlike Sprig, where function naming varies between camelCase, and snake_case, and similar functions lack consistent prefixing, Sprout will introduce a standardized approach to function naming. This will make the library more intuitive and reduce the learning curve for new users.

Tip

This convention are defined and writed to available here: Templating Conventions

4. Reduce memory fingerprint

Aim to minimize memory allocations as much as possible to alleviate the burden on the garbage collector in large-scale applications. By optimizing the way memory is used within the framework, we ensure that Sprout is not only efficient in its functionality but also in its resource consumption. This approach contributes to overall better performance and scalability of applications using Sprout.

• perf: reduce all memory fingerprint #56

5. Native Error Handling

Introduce built-in error handling mechanisms for all functions to ensure that errors are managed gracefully and efficiently.

Warning

An RFC is currently open for feedback and discussion. You can view and participate in the RFC here.

6. Advanced Error Handling Strategy

Implement a custom error handling framework utilizing channels for improved error reporting and handling on the Go side, reducing the risk of template crashes.

• 🌱 error handling: create a complete and robust error handling #6

7. Expanded Function Set

Add a broader array of functions without imposing limitations, enabling users to accomplish more tasks directly within the framework.

8. Customizable Function Loading

Allow users to customize which functions to load into their runtime environment, preventing unnecessary resource consumption and enhancing performance.

• 🌱 functions loading: create a complete solution to load specific function #10
• 🌱 custom functions: allowing developers to create their own functions #11

9. Function Aliasing

Enable the creation of aliases for functions outside of the library, providing flexibility and convenience in how functions are accessed and utilized.

• 🌱 functions aliasing: allow to create alias for existing functions #3

10. Function Notices

When you are a middle-app (between sprout and the user how write the template), you need to be careful when you upgrade a template library due to potential breaking changes or deprecated functions.
The solution are to embed a notice system in the template library to warn the end-user of a deprecation and let x versions between the deprecation notice and the replacement / removal of the function.

• feat: add notice on function call to inform or warn the end-users #58

The Path Forward

Achieving these objectives will require a collaborative effort. We're calling on developers, documentation specialists, and anyone passionate about creating a more efficient and user-friendly template function framework to contribute. Whether it's through coding, providing feedback, or contributing to documentation, every bit of help pushes us closer to our goal.

How to Contribute

Interested in contributing? Here's how you can help:

Code Contributions: If you're a developer looking to add new features, improve existing ones, or help with bug fixes, check out our issues section and pick something that interests you.
Documentation: Good documentation is key to any project's success. If you have a knack for writing and wish to improve our docs, we'd love to hear from you.
Feedback and Ideas: Have ideas on how we can improve Sprout? We're all ears. Open an issue with your suggestions, no matter how big or small.

Conclusion

Migrating to Sprout represents not just the evolution of a framework but a collective journey towards building a more resilient, efficient, and inclusive tool for developers. With your support, we can create something truly special that stands the test of time and serves the needs of the community. Let's grow together! 🌱

[42atomys]

You can now retrieve all informations directly on the documentation site : https://docs.atom.codes/sprout/roadmap-to-sprout-v1.0

[andig]

I don't find the related comment but I'd agree that it would be great to have an org if this should be a long-term evolution of sprig.

[42atomys]

Thanks @andig for suggesting we move the project to an organization. I’m seriously considering it! However, I’m a bit concerned about the potential disruptions it could cause at this early stage of the project, I use features from GitHub Team, and migrate to an organization force to me to repay it. I still open to your inputs 🌱

To manage imports, I’m thinking about setting up a vanity URL (following the doc site, so something like atom.codes/sprout). This will allow us to migrate without disruption in the future. Does that sound like a good interim solution? I’d love to get your feedback with emojis 👍 or 👎!

Your insights are incredibly valuable to me, so please don’t hesitate to share your thoughts!

See you 🌱

[andig]

Does that sound like a good interim solution?

I honestly don't know. It was horrible (but also done very late) for mergo.

[42atomys]

It was horrible (but also done very late) for mergo.

Yes agreed do it too late can be a nightmare and broke a lot of things.

I love vanity for the flexibility that give to maintain transparently from the end devs, but I hate it for the SPOF that can create

[ripienaar]

There has been several renames - mergo, expr, logrus comes to mind immediately - and to be blunt it was all a complete disaster for users, there are no good outcomes from renaming a project.

I'd say this being in a org is a MVP level requirement to avoid the issues we are trying to get away from.

And no, not a vanity url either - a github org.

[andig]

I've claimed https://github.com/go-sprout (sprout is not available). Let me know if you'd like to hand that one over or if there are better ideas.

[42atomys]

I try to takes go-sprout too ahah
After few combinations of sprout and go and don't found one, I take "gardenkit" and in future maybe grap other repo to maintain it in a beautiful garden 🪴

I currently facing to the "pay" issue due to the charge that add for me to double pay the Pro features (for me account and for the org)