[#153] Add a standard way to add add-ons manually

[hoangmirs]

• Close #153

What happened 👀

• Refactor to make the CLI can install individual add-ons to the existing project. The project should be generated from this CLI as well
• Support the blank infrastructure type which generates a blank project with some core files.
• In each module, we check and skip if it was installed, and also install the dependencies if needed.
• Create Install command to install custom add-ons, for now, it just supports AWS modules
• Support to use tsconfig-paths

Insight 📝

• Although we're using synchronized functions, I added the async/await to almost functions to make them support other async libs as well. So we don't need to care if a function is async or sync and force the application to use await instead.
• Before we could not use the paths from tsconfig.json because OCLIF doesn't support it. I follow this issue and found a way to do that by customizing a bit on the execute files and modifying jest.config to support reading the paths in tests
• You can test this by running the following steps:
  • Pull this branch, and stay at this project root
  • ./bin/dev generate nimble-test to create a new project, you should choose blank template to be able to install more addons
  • ./bin/dev install vpc --project nimble-test to install vpc add-on to nimble-test project folder or you can change current directory to cd nimble-test and run ../bin/dev install vpc instead, it will install to the current folder
• The guide to add a new add-on to the template will be added later once we complete setting up the WIKI

Proof Of Work 📹

Add-on that doesn't require any dependencies
Add-on that requires another
Terraform init successfully

[Nihisil]

@hoangmirs

Although we're using synchronized functions, I added the async/await to almost functions to make them support other async libs as well. So we don't need to care if a function is async or sync and force the application to use await instead.

When would we need to use an async library for generating project files? I can't think of any case yet, and adding async/await to all methods now looks not really readable to me

[malparty]

While I understand we want a separate PR for adding the documentation, I think we should not wait for the Wiki. Can we draft documentation in the README.md? This can be done in another PR, but this documentation would be very helpful for me.

While it's comfortable to be able to "auto-import an addon", I'm trying to answer the below question:

Which one is more painful?

• to manually copy the needed files each time we want to install a specific add-on to an existing project?
• complexify adding a new add-on or provider to our template***

***I don't know how much this PR complexify it 🙇

[hoangmirs]

Which one is more painful?

• to manually copy the needed files each time we want to install a specific add-on to an existing project?
• complexify adding a new add-on or provider to our template***

TBH, I feel they are the same, as to support the CLI adding a new module, we will do the same step as manually copying the folders/files, but we make it with coding. Therefore, to adding a new module, we just need to understand the step and describe it in the code: what is the needed files/folders, what is the steps, how to we add to the current project,... This code will look like a guideline, you can reference it to process the copy:

And if the generated project is using our template to generate, then it will use our folder structure, and the CLI can easily add the support modules to 😄

[malparty]

Since my last comment, I think I also better understand the structure of this template, so I am less concerned by the template complexity as it is less complex than I imagined 🙈 So that part is all good now 👍

[hoangmirs]

@olivierobert @longnd @malparty Could you help me recheck this PR? 🙏