axodotdev / axoproject

🍱 project structure detection for axo's toolchain

⚠️ Project moved ⚠️

This project has been moved into the cargo-dist repository. Further development will occur there.

axoproject

A tool that handles the details of detecting a cargo/npm workspace/project at a given directory, and making sense of the structure. This should be used by cargo-dist and oranda to share that logic.

License

Licensed under either of

• Apache License, Version 2.0, (LICENSE-APACHE or apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or opensource.org/licenses/MIT)

at your option.

axoproject's Issues

project detection should probably be iterative

If you run axo-project tests/projects/npm-init-legacy, instead of detecting the npm project it will detect axo-project's Cargo project, because we exhaustively search for a Rust project before ever searching for an npm project.

Probably we should check for both kinds of project in each directory before walking up the ancestor?

need better diagnostics when failing to find projects

If you're in a malformed Cargo workspace (such that cargo metadata will error out), all we say is "failed to find a workspace" without any additional context. We should endeavor to provide/forward better diagnostics here. This is made more complicated by the fact that we are sniffing for two different kinds of workspace, so one failing is "normal".

We need some way to distinguish "it kinda looks like there's a project but it's messed up" from "it doesn't at all look like there's a project".

More broadly we need some way to properly factor out the separation of concerns for reporting these issues. Right now I just unconditionally warn! from within axoproject which is uhhhh suboptimal. Unfortunately cargo-dist and oranda currently completely disagree on their error/logging systems, so this might necessitate buffering everything up into properly typed structs/enums/vecs..?

Add override for changelog path

Of the 3 autoincludes (readme, license, changelog), changelogs are the only one without any support for a manual path that wins out over auto-includes. As a result, there's no way to disambiguate when you have a CHANGELOG and CHANGELOG-OTHER or whatever. We kinda just... pick one.

axoproject/src/rust.rs

Lines 250 to 256 in af87635

	readme_file: package.readme().map(|readme| package_root.join(readme)),
	license_files: package
	.license_file()
	.map(ToOwned::to_owned)
	.into_iter()
	.collect(),
	changelog_file: None,

The annoying thing here is for the other two we're relying on Cargo having a builtin notion for license/readme paths, but it has no such notion for changelogs. As a result we'll need to define our own under metadata.dist, which axoproject isn't "supposed" to read but honestly I expect that separation isn't long for the world, so whatever let's just read out that one field.

remove "announcement" code

currently some code still refers to the cargo-dist concept of announcements- i think ideally this does not exist in axoproject.

we may want to provide a utility function to select/filter portions of the workspace based on version number (which is ultimately what the announcement functionality does) but we should call it "filter" or something like that

include version number in output

esp for cargo-dist, where version number is uniquely load-bearing, this feels like a useful but not super overwhelming piece of data to include in the output, esp given that the toolchain is focused on publishing/releases

expose cargo categories/keywords

The purpose of this is to translate the concept in cargo to the concept in npm. Cargo has both the notion of a "keyword" and a "category" but they're largely the same thing and I think it's fine for us to flatten them into a single "keywords" field (at least for now). You'll need to add a new field to the PackageInfo type.

• use these guppy APIs to get the values
• insert them somewhere around here

You will also need to mirror the field in main.rs around here, which will expose it in our json output (for web APIs).

If keen, do the same for npm:

• use this oro_common field
• insert them somwhere around here

optional arg first is confusing in `get_workspaces` fn

https://github.com/axodotdev/axoproject/blob/main/src/lib.rs#L335

Use parse_changelog::Release::title_no_link

axodotdev/cargo-dist#262

https://docs.rs/parse-changelog/latest/parse_changelog/struct.Release.html#method.title_no_link