cli

@projector-js/cli

• The --root argument, when used in a polyrepo context, refers to the repository root and can usually be omitted.
• -w vs -p

  The p and alias projector command comes from npm i -g @projector-js/cli. Alternatively, npx can be used: npx projector ... (when installed locally) or npx projector-js ... (when not installed).

• glob -w has a specific priority order
• create has alias init
• --parallel vs --concurrency 1 (or N) vs --sequential
• confirm when calling create within a directory that contains a package.json without workspaces field. --monorepo (and all other options) settable from CLI; still, ask via inquirer too.
• tests and some other commands are done from root
• clean command that calls clean script eventually but also cleans up tmp articles in /tmp and elsewhere
• git output symbols inspired by https://github.com/spaceship-prompt/spaceship-prompt
• in monorepo mode, publishing from the main repository is not possible
• package-id used for git tags
• publish will fail if whole repo is not clean
• publish will fail if not enough disk space remaining
• Caveat: publish command in a monorepo context trades off disk space for perf (concurrency).
• publish will keep temp release dirs around
• publish will bind mount node_modules and any other files and dirs specified in .gitignore
• If going with conventional-changelog, consider using the CLI version patched to work properly with monorepos:

  npm install --save-dev https://xunn.at/conventional-changelog-cli

---

• Install
• Usage
  • CLI Options
  • API
• Examples
• Related
• Appendix
  • Published Package Details
  • License
• Contributing and Support
  • Contributors

Install

npm install --save-dev @projector-js/cli

Usage

CLI Options

API

Importing CLI as a Module

Although typically unnecessary...

Examples

Related

Appendix

Further documentation can be found under docs/.

Published Package Details

This is a CJS2 package with statically-analyzable exports built by Babel for Node14 and above.

Expand details

That means both CJS2 (via require(...)) and ESM (via import { ... } from ... or await import(...)) source will load this package from the same entry points when using Node. This has several benefits, the foremost being: less code shipped/smaller package size, avoiding dual package hazard entirely, distributables are not packed/bundled/uglified, and a less complex build process.

Each entry point (i.e. ENTRY) in package.json's exports[ENTRY] object includes one or more export conditions. These entries may or may not include: an exports[ENTRY].types condition pointing to a type declarations file for TypeScript and IDEs, an exports[ENTRY].module condition pointing to (usually ESM) source for Webpack/Rollup, an exports[ENTRY].node condition pointing to (usually CJS2) source for Node.js require and import, an exports[ENTRY].default condition pointing to source for browsers and other environments, and other conditions not enumerated here. Check the package.json file to see which export conditions are supported.

Though package.json includes { "type": "commonjs" }, note that any ESM-only entry points will be ES module (.mjs) files. Finally, package.json also includes the sideEffects key, which is false for optimal tree shaking.

License

See LICENSE.

Contributing and Support

New issues and pull requests are always welcome and greatly appreciated! 🤩 Just as well, you can star 🌟 this project to let me know you found it useful! ✊🏿 Thank you!

See CONTRIBUTING.md and SUPPORT.md for more information.

Contributors

See the table of contributors.