Provide default configuration for TypeScript on `project:create`

[joaquingatica]

Contact Email

[email protected]

Type of Contribution

Feature Request

Product

SuiteCloud CLI

Contribution Description

The overall goal of the proposal is to help improve type-safety in SuiteCloud projects. TypeScript is the obvious choice, and some level of official support for it is appreciated.

But I understand it may not be the best idea to have the SuiteCloud CLI compile and handle TypeScript code. We should avoid the CLI being owner of the developer's toolchain, given that SuiteScript itself doesn't support TypeScript files.

Why support TypeScript the first place?

From a customer success point of view, and from a service provider standpoint, we often face the fact that we either don't own the original codebase (the customer does) or we may not own it forever (may transition to the customer or to other company). This mostly applies for Account Customization Projects.

So whatever we do, if we want to do it right, it can't prevent the customer from getting official support moving forward. Specifically, we can't guarantee that the customer's team (or whatever software company comes next) will be knowledgeable in TypeScript. So more often than not, using TypeScript in an ACP is not the best decision for the customer's long term success.

If there was some recommended way of implementing TypeScript in SuiteCloud projects, however basic, then the customers or other software companies should be able to learn off the recommendation and get official support, since now it would be an official option in the developer tools.

Proposed solution

By providing an initial scaffolding (such as it's done for jest) during project:create: it indicates some level of official support, enables ease of TS usage, without preventing ownership and customization of the toolchain by the developers.

For unit testing, currently we have the following prompt:

Do you want to include unit testing with the Jest testing framework? ***This will install NPM module dependencies.

For example, something like the following would work:

Do you want to include TypeScript configuration and build step? ***This will install NPM module dependencies.

If selecting Yes, then the initial scaffolding of TypeScript configuration would be will added, mimicking the behavior of the initial scaffolding of jest testing. After the initial creation, the developers would own the maintenance, update or changes to the configuration.

This way the CLI provides a recommended starting point, but doesn't need to maintain ownership of it moving forward, and doesn't restrict the developers of making changes to it.

Prerequisites

Yes, I have completed the prerequisites.

Additional Information

Suggested configuration to be added

This is not an exhaustive list, but the following things would be nice to be setup on the initial scaffolding:

• typescript, @hitc/netsuite-types and any other relevant dependencies to be added as devDependencies
• A tsconfig.json to be created with initial configuration
• In the package.json:
  • Add a new script for type-checking (i.e. "check": "tsc --noEmit")
  • Add a new script for building (i.e. "build": "tsc")
• In the suitecloud.config.js, logic to compile the project to be added in the beforeExecuting hook for relevant commands (i.e.: "project:deploy", "project:validate")

Alternatives for folder structure

There are some options I can think of regarding the folder structure to support TypeScript. Depending if the TypeScript source should go in the defaultProjectFolder or elsewhere.

Option 1) Use TS files inside defaultProjectFolder (i.e. a single src folder)

• Pros:
  • TS and JS source can co-exist
  • No need to customize object:import when downloading files
• Cons:
  • TS files will be deployed to the file cabinet (unless customized)
  • Compiled JS files will be versioned in Git or any VCS (unless heavily customized)

Option 2) Use TS files in separate folder, defaultProjectFolder will be the TS output folder (i.e. a src folder for source files, a dist/out folder for built files used as defaultProjectFolder)

• Pros:
  • All JS files can be ignored from Git or any source control, by ignoring the whole defaultProjectFolder folder
  • TypeScript files won't be deployed to the file cabinet
• Cons:
  • TS and JS files can't easily coexist in the same project (unless customized)
  • Non-TS files (i.e. manifest.xml) need to be copied to deploy folder before deployment (since tsc doesn't do it)
  • Non-JS files (i.e. XML) downloaded via object:import will need to be copied or moved to the sources folder
  • JS files downloaded via object:import would need to be dealt with (warn the developer to look for them in the defaultProjectFolder)

Option 3) Use TS files inside defaultProjectFolder but outside the FileCabinet folder, tsc builds into FileCabinet

• Pros:
  • TS and JS source can co-exist
  • No need to customize object:import when downloading files
  • TS files won't be deployed to the file cabinet
• Cons:
  • Compiled JS files will be versioned in Git or any VCS (unless customized)
  • JS files downloaded via object:import would need to be dealt with (warn the developer to look for them in the defaultProjectFolder)

Regarding object:import

Regardless of the option chosen for folder structure, a fact remains: when performing object:import including source, if the source was originally compiled from TypeScript, the compiled JS will be downloaded only.

This is expected, and not a problem in itself. I believe that when there's a matching local TS file for an imported JS file, it would suffice to just log/notify/warn the developer of that fact, so they're aware.

In the end, it is expected that the source of truth will be the TS files locally, not the compiled JS files imported. But still worth the warning, so the developer knows if they should be careful somehow.

Additional Notes

I'm more that happy to follow up with additional conversation, providing further thoughts and opinions and even contributing with implementation. I wanted to first outline the initial gap and proposed solution, to then move to collaborating whenever possible. Feel free to reach out however is most convenient. Thank you!

[veronicacbs]

Hi @joaquingatica ,

Thank you for your feature request and for your willingness to contribute! We’ll review this idea with the team and get back to you soon. Thanks again for your engagement and support for our tools!