build: update scaffolding for creating unary math iterator packages

[gunjjoshi]

Description

What is the purpose of this pull request?

This pull request:

• adds runner.js in _tools/scaffold/math-iter-unary/scripts to generate packages in math/iter/special.

Related Issues

Does this pull request have any related issues?

This pull request:

• resolves a part of [RFC]: support for structured package data #1147.

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

---

@stdlib-js/reviewers

[gunjjoshi]

While running this, I get the following error:

[gunjjoshi]

I thought to update scaffold.sh once we have a basic working script.

Along with that, are we also thinking to update our scaffolding structure (https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/_tools/scaffold/math-iter-unary/data), as our meta data does not contain some of the fields used in that.

[gunjjoshi]

What are we using this for: https://github.com/stdlib-js/stdlib/blob/develop/lib/node_modules/%40stdlib/_tools/scaffold/math-iter-unary/scripts/data.json#L3 ?
With this included, I get the error:

/bin/sh: =math/[email protected]: No such file or directory

When I remove this from data.json, it works, and the packages are being made at the required path.

[gunjjoshi]

Made a few changes, the structure is generated correctly now.

[kgryte]

Okay. I think this is now ready for merge. I made a number of changes, @gunjjoshi. In preparation for other scaffolding tools (which will get more complex!), probably worthwhile studying the changes and reverse engineering why I made the ones that I did.

Some things won't be obvious (e.g., replacing backticks in require paths in index.d.ts files => historical artifact due to prior tooling limitation), while others rely a bit more on understanding that there will be exceptions we'll need to account for (e.g., relying on DESC to provide a default description will work for many cases, but there will be other packages in which we cannot do this and need to be more particular about specifying PKG_DESC, MODULE_DESC, etc).

[gunjjoshi]

Thanks for making these changes, @kgryte. I'll go through them once so that we follow the latest conventions in future packages.