Feat/mantis new cli

[babacarbasse]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/mantis-apps/mantis-cli/blob/master/CONTRIBUTING.md
• All code passes linting (npm run lint:all) and formatting (npm run format:all) checks
• Docs have been added / updated if relevant

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[RyanClementsHax]

Overall this is a pretty big rearchitecture of how templates will work. Instead of shipping them with the cli, we dynamically create the workspace and copy some files over from a different repository.

This has the benefit of not needing to ship a new version of the cli when we want to update certain files in the template, but create-nx-workspace could radically change its output or include unnecessary things that break the assumptions the template makes resulting in a broken repo.

I also see this PR being very large including the aforementioned rearchitecture, but also a new generate command. Could we split this into separate PRs? I don't want to block your work on the generate command due to discussions on the rearchitecture.

[RyanClementsHax]

Does @todo need to be updated to be generic to the project name?

[RyanClementsHax]

This would need to be generic depending on the package manager used.

[RyanClementsHax]

question: why use this when we already have enquirer? I'm ok if we want to switch. We should just standardize on one though.

[RyanClementsHax]

This would need to be generic depending on the package manager selected.

[RyanClementsHax]

nit: could we list out all the different "things" that could be generated?

[RyanClementsHax]

+1 for adding flags for this

[RyanClementsHax]

Could you describe what the mantis.json is to be used for? It seems we can get this information elsewhere.

name: This can be found in package.json
version: This can be found in package.json by inspecting the versions of the packages installed
workspace: What is this used for? If this is to give a relative directory to the root of the mantis project, why not expect all commands to be run within the nx workspace i.e. the root?
description: This can be found in package.json
packageManager: This can be inferred using nypm

[RyanClementsHax]

Let's standardize on the names to use. I've been using web-client and mobile-client, but I see you using different ones. Let's discuss this further. @adyngom What do you think?

[RyanClementsHax]

The command is a little more complex than this. Could we support running the local db as well if selected?

    await execa(
      'npx',
      [
        'nx',
        'run-many',
        startLocalDb ? '--targets=serve,start-local-db' : '--target=serve',
        '--projects=web-client,mobile-client',
      ],
      { cwd: workspacePath, stdio: 'inherit' },
    );

[RyanClementsHax]

A few things to note.

Could we update the prompt to be clear that we will set up the db for the user? The original prompt used the following options:

      {
        name: 'Create a local development mongo db for me (default)',
        value: 'local',
      },
      {
        name: 'Provide a mongo connection string',
        value: 'dbUrl',
      },

Secondly, can we make the db unique to the project? We wouldn't want every mantis project the user creates to connect to the same db.