Swift Run scripts

I would agree. I didn't know about the unnumbered, WIP, Package Manager Extensible Build Tools until now.

Coming from Node JS you could define run-script commands in package.json:

"scripts": {
    "start": "node server.js",
    "seed-db": "node ./scripts/seedDatabase.js 
}

And then simply run them from the command-line:

npm run-script seed-db

This pattern made testing and deployment easier as in this example I can call npm run-script seed-db to seed the database and then call the npm start to start up the server.

In swift there is a single start point in main.swift, so a work around where you could define the start point for each script would need to be sorted out.

All in all, I think this is a major feature that would benefit SwiftPM in one form or another.

Quick check here: How is this a win over writing Utilities/docs.sh, Utilities/format.sh, Utilities/lint.sh, Utilities/ci.sh, and Utilities/deploy.sh?

Shell scripts (or Swift scripts!) in a folder are way more flexible in terms of chaining commands together and implementing custom glue logic, they already have ways to handle problems like escaping and command-line arguments, and the package manager already supports them today (by not caring that the Utilities folder exists). What does having a scripts: section in the package description offer us?

I just gave a talk at swiftcloudwork.shop about building command line tools! There's an existing tool out there called Beak, which makes building task-runners in Swift super simple by leveraging SourceKit. It might be a good fit for what you're trying to do. https://github.com/yonaskolb/Beak

My talk included lots of links to other open-source tools, too. If you're interested, here are the slides: http://mklbtz.com/2018/11/18/command-line-toolbox.html

2 Likes

I think the biggest thing it gives us is a unified development experience for Swift. One of the main strengths (and one could argue, weaknesses) of node.js is its package ecosystem and the defacto standard of npm and the unified experience it gives you. Most node projects I've worked on use npm as the primary tool used to interface with the project and its tasks.

It's this standardization around the "package manager" as the default tool for working with a Swift project that I think would be the value. Now like I mentioned upthread, I think there is room to explore what a unified development experience for Swift would look like. (Keep expanding the scope of the manifest, add a new kind of tool with a corresponding Tasks.swift, etc)

4 Likes
Terms of Service

Privacy Policy

Cookie Policy