A Cargo manifest for JavaScripters

A little push to those JavaScript/Node.js developers who are discovering the Rust world (like me)

After a long time flirting with I decided to start (and finish!) a simple, but useful, crate. So I spent quite time understanding and looking for the most similar setup to my experience with Node.js.

My main goal was to use the Cargo manifest to set up everything, avoiding Makefiles and shellcode as much as possible.

From the first block, the unique not familiar thing should be the edition field. I suppose youre starting a new project, so just use 2018. As you can suppose include is the equivalent to files in npm.

Related with this, one of the most impressive things is that modules of both editions can work together. And all of them are going to be maintained forever! . I totally recommend the next presentation where I learned it a couple of days ago.

The second block, at this point only categories could call your attention, this is the list with the options. As a curious note, only five are allowed and the same happens for keywords, and I think this limit is a very good idea. Honestly, I can imagine npm also limiting it, but Ive never reached it.

Another important thing is to include the readme (and documentation) fields because both are used in the crates.io site.

I also liked the idea of including here the project badges. They are also shown on the website. For now, is a bit redundant to have them also in the README, but probably GitHub will support them soon .

As I commented a must is to avoid shellcode as much as possible, and the cargo subcommand cargo-cmd came to the rescue. It implements the same idea under the npm tasks.

Here the rest of replacements Im using today:

• cargo-edit: npm install-S (and -D).
• cargo-audit: npm-audit, former nsp.
• cargo-release: Similar to np.
• cargo-outdated: depcheck.
• cargo-sync-readme: To avoid code redundancy keeping sync the Rust documentation and the README.
• rustup: The components rustfmt and clippy are the linters here.

To deep into every supported field visit this section of the Cargo book.

As a bonus I have also included a couple of dependencies which makes me feel comfortable:

• simple-error: To keep the error handling simple, but doing things right. I mean, avoiding the panics, using monads, and all these things I use to speak about with my friend Jorge after some beers .
• pretty_assertions: Better errors in tests.

Before finishing I would like to drop this nice book which helped me a lot and covers some of the tips commented in this post.

You could ping me on Twitter if you want to speak more about this topic.