At what stage of a project should I publish or make available on github?

community
1

TL;DR: I have a project in an early stage and don't know when I should publish something(cargo and github). I would like to get community help, and I want to encourage long term adoption if the project is successful, but it's currently a single component of a larger project useless on it's own, and the implementation of each component is likely to change in a way that breaks things if people decide to build on it.

I'm working on what I hope will be a cross editor snippet manager, Sniper, which uses a superset of LSP's snippet syntax specification, and meant to have features that don't seem to be offered by other snippet managers(essentially my goal is ultisnips feature parity with a few extras). Plus, if it really does become partially editor agnostic, you'll have mostly the same snippet capabilities across multiple editors, similar to how language servers offer mostly the same capabilities to multiple editors.

It's composed of 3 parts:

  • Sniper-core
    • all the stateless logic(and components for handling state), are defined here.
    • handles deserialization and storage of snippets
  • Sniper-{LANGUAGE}
    • the first target is node via wasm, followed by java or python(via pyO3)
  • Sniper-{EDITOR}
    • written in whatever language is either easiest to write or implement for that editor
    • first target is vscode via typescript, then either kakoune via python or eclipse via java
    • actually handles state, such as tracking user input and deciding when to suggest/insert a snippet.
    • may leverage interaction with the language server for the target language in order to have smarter loading or completion

with a 4th component I'm considering:

  • snipe
    • a download manager for snippets for language/library x
    • if it becomes actually editor agnostic, it makes sense not to leave this to just bulk download everything or leave it to editor X

This is meant to handle snippets for multiple libraries which will be loaded as needed. For example serde snippets would get loaded either when importing serde, or sniper becomes aware somehow that you are using serde; snippets can also be composed of other snippets to make implementations of larger blocks of code(and file templates) much easier for the user.

I have the parts of sniper-core defined, confirmed that I can deserialize a few toml files containing snippets, and that I can grab them. I started a vscode extension last night via a yo template and started reading on compiling rust to wasm which, unless I'm missing something, after reading the Mozilla page on it seems to be a lot easier than I thought it would be.

Because pretty much every aspect of this project is a first for me, I can't really go any further with the core library without learning what I can and can't do with the editor and LSP. I also may change the nature of how much is handled by the core library (making more and more editor agnostic after I build an editor interface). I may change from toml to json if it turns out to make more sense to use a StreamDeserializer which doesn't seem to have an equivelent in the toml implementation. I have plenty of other parts that are likely to get rethought or reworked once I have a basic working POC for an editor.

So given that this project is composed of multiple parts, each which is useless without the other, and that once each is defined (because I'm unlikely to implement it for every editor in existence) other projects may break if people start building on it while I'm still figuring out the best way to skin this cat, when is advisable to publish my project, both on cargo and on github?

2

I would not suggest publishing to crates.io until you have something working and want to maintain it in the future.
The benefit is small and if your code changes often, the crates.io version will be constantly outdated.

3

So first off, your project sounds pretty awesome and I'll be keen to see how it grows in the coming weeks and months. I largely use VS Code's snippets these days, but I can definitely see the benefit of a snippet engine which can be plugged into multiple editors.

It also sounds like you've put a lot of thought into your project structure and how the various components interact.

It sounds like you are overthinking things :slightly_smiling_face:

I usually push a project to GitHub almost immediately after running git init my_project. When a project is on GitHub you get backups for free, you can use the issue tracker for tracking your progress and as a place to discuss ideas (even if you're just discussing with yourself), and you can set up CI so that every commit you make automatically gets compiled and tested. Sure once it's accessible to other people you run the risk of people using your things, but that isn't necessarily a bad thing.

Usually I'll publish to crates.io when I believe the project has enough implemented that it could be useful to someone.

There's nothing wrong with giving people access to something that is still evolving. Normally what you'll do is mention in the project's README.md that the project is still evolving and you are figuring out how the pieces should fit together.

The people who might build on your project are going to be early adopters accessing it from GitHub, and early adopters tend to be okay with a little extra maintenance burden. It's a part of being on the bleeding edge. There's a good chance they'll create a ticket and from there you can

1 Like
4

I went ahead and published what I have to github, I wrote a readme, contributing guideline and a few notes on the snippet specification not covered by the existing one. I probably need to add an apache license

I usually push a project to GitHub almost immediately after running git init my_project . When a project is on GitHub you get backups for free

I normally do too, but usually I'm writing something either for me or for classes. Plus I'm kind of obsessive about writing clean code, or at the very least not terrible code. This is my first attempt at writing a larger program meant to be used by other people, and also my first attempt at an actually useful rust program, and is going to be my first typescript program/vs-code extension. So I suspect it's going to be pretty terrible before I get far enough in to start refactoring.

There's nothing wrong with giving people access to something that is still evolving. Normally what you'll do is mention in the project's README.md that the project is still evolving and you are figuring out how the pieces should fit together.

Yeah, I was definitely overthinking it but I've seen a couple open source projects that had no problem changing configuration options even after becoming stable, which led to people having to figure out why something they wrote broke when it updated.

It was also that the idea of the project is something I'm kind of invested in. Certain hurdles probably require a lot users, and this project or another project like it would be really beneficial so long as it was popular enough.

I tend to have more ideas than I can actually hope to implement, and as such I've looked into a lot of code automation solutions in the past year or so: file/project templating, snippet managers, etc. they are either a language in and of itself, so cookie cutter as to be useless outside of a very specific usecase, or tied to a single editors and a few developers, which limits the capabilities and fundamentally limits the utility.

Finding the right spot between boilerplating and creating something new is tricky. The ideal scenario is for the user to be able to flesh out an idea as fast as they can work out the logic. It's kind of like smart cars today: the person is still in the driver seat but only has to concern themselves with A->B, rather than how to parallel park or if that asshole in front of them is going to abruptly slam on their breaks.

In order to build up a massive enough library of snippets that you could have the best of both worlds, to where the user only has to worry about the logic and not the time consuming component of implementation, while having the degree of creative freedom that comes with figuring things out as you go along, you need a lot of users creating a lot of snippets for a lot of libraries. and then some way for people to share them and compare them. Think of it as naturally selected automation.

I guess I was worried that by releasing early I would be harming the long term chances of people actually using it, because they would try it, it would be broken, and then they would assume that was because it was crappy software, rather than still under development.

5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.