feat: add liara init command

[Mortza81]

This command provides an interactive process to generate a basic liara.json configuration file.
The generated configuration file will include only the basic parameters to get started, such as application name, port, platform, and other necessary fields. However, any additional or advanced configurations (such as cron, healthCheck, etc.) will not be included by default and must be manually added after the file is created.

[jarqvi]

related: #151

[vashian]

I suggest avoiding the use of null here.

In JavaScript, undefined is the default for uninitialized or missing values, which helps align with the language's conventions. Using undefined simplifies checks and ensures consistency, reducing the need to handle both null and undefined separately.

I think when designing APIs, returning undefined for missing data is often more intuitive and aligns with JavaScript conventions.

export default function supportedVersions(platform: string) {
  return versions[platform as keyof typeof versions]
}

Test it and let me know what you think!

[Mortza81]

You're right! Also we can simplify the null checks in the init.ts file (lines: 272, 227, 291). Since both null and undefined are considered falsy in JavaScript, we can replace the explicit null checks with a straightforward truthy/falsy evaluation.

For example:

if (platformVersion == null) {
    return null;
}

Can be simplified to:

if (!platformVersion) {
    return null;
}

If you agree with this approach, I’ll proceed with committing these changes.

[vashian]

I noticed that the promptPort method is repeated in deploy.ts as well. Additionally, base.ts doesn’t seem like the appropriate place for a utility function like this.

Why not move promptPort to the utils directory? This would allow us to reuse it wherever needed and keep base.ts focused and simple.

Keeping base.ts as clean as possible is important for maintainability and readability.

[Mortza81]

I tried to follow the approach that has been used so far. there is also promptNetwork() and promptProject() that is defined in base.ts. I suggest that we let them be in base.ts for now and move them later.

[vashian]

Why not move these interfaces to the types directory?

[vashian]

Appropriate errors should be thrown to inform the user.

[vashian]

IMO :

The typeof operator gives misleading results for null:

typeof null; // "object"

Handling both null and undefined leads to verbose checks. For example, default parameter values only work with undefined. If a parameter is explicitly set to null, the default value won't apply:

function greet(name = "Guest") {
  console.log(name);
}
greet(null); // Outputs: null

Default values in object destructuring also fail with null, and using null in nested destructuring can even cause runtime errors.

These are the main reasons I avoid using null. Since @mhemrg and I have different perspectives on this, I think it’s a good idea to ask for his review on the PR to ensure future consistency.

[mhemrg]

Suggested change

	Afterwards, use liara deploy to deploy your project.
	Afterwards, use liara deploy to deploy your app.

[mhemrg]

Don't we need an await for this?

Suggested change

	this.createLiaraJsonFile(configs);
	this.createLiaraJsonFile(configs);

[mhemrg]

The following pattern:

try {
  //
}
catch (error) {
  throw error;
}

Doesn't accomplish anything. You can remove them all.