No not the project todo sorta thing. The engineering kind where a person creates a project and brings in all sorts of tooling to help them manage their project. Really important to know the tools out there. For this post I'll focus on NodeJS, since it is odd.
If we look at NPM land, they brand themselves as a package manager, but it also runs tasks. When you create a new package, you use `npm init` which will ask you some questions about it. You could have multiple packages in one folder... maybe because you are working on one project that involves multiple components. Say a set of libraries, services and applications such as CLI or UI. You'd want to to do `npm init` for each component you intend to create. Now when you want to reference your library from an application, you'll have to add it to package.json. Luckily npm supplies an easy way to do that.
Let's fast forward to the point when application is now including multiple libraries and some of those libraries other components. Now you want to update a root component, like a foundational component, that means publishing a new version (bump) and then bumping up all the dependents. Bumping up the dependents means `npm install` then `npm run build`, `npm run test` probably some bug-fixing and then publishing.
These are really common operations in the lifecycle of an npm project. I want tooling that can simplify the interactions without forcing a new workflow through some non-npm/yarn command nor trying to make things more efficient. @Microsoft/rush came close to being the node project manager of choice, but it is still new, some choices I don't like (`rush change` is super narrow) and has kinks to work out. Lerna and yarn workspaces did not workout for me. Dissatisfied by the choices, I decided to make my own project manager.
I simply want to list my project's components and the language used. A CLI can read that descriptor file and create some cached metadata about the components themselves. Build ordering, publish ordering, version management, linking and etc. don't require some new way of structuring your directories to fit. I'm really not sure why some tools force you to pick a structure for your project. For NodeJs, you only need to know where the package.json is then package management operations can be run. If you have a build order of those directories then you can easily do package install, link, build and publish operations in the proper order. If you have a graph of dependencies in you project then you can invoke builds of those dependencies and their dependencies until the intended project. When I traverse to a directory with package.json (assuming the package is part of a project) I can invoke build which will build all project dependencies, which is beautiful for applications with internal modules. Another point is keeping package dependency versions consistent, so I found a tool out there that does this wonderfully and I added it to my CLI. I want to expand that idea outside of NodeJs and in to Java (gradle) and Rust (cargo). In the future, I'd like to have a master dependency list published internally that the CLI can leverage to do syncs and version checking. It would make deprecating library versions easier to do as well as scanning all repositories for delinquent versions.
That's what I did. Nothing complicated. Just wanted to automate the manual commands I was already running (linking is annoying as hell to do since they go away after install). I do plan to see what kinds of other tools are out there that I can add into the project. I'm lucky that gradle and cargo do some of these things from the get-go, so I don't have to implement those parts.