Type checking in the build process

[christophstockinger]

ℹ️ Port of the react-starter-kit laravel/react-starter-kit#37

---

This pull request adds a tsc (TypeScript Compiler) task to the build process. Currently, the build pipeline does not include a TypeScript type-checking step, which means that potentially erroneous TypeScript code could be deployed to production without being caught during the build process.

By incorporating the tsc task, we ensure that type errors are detected early in the build cycle, preventing invalid or mis-typed code from being pushed to production. This enhances the overall stability and reliability of the codebase and reduces the risk of runtime errors caused by type mismatches. Type checking during the build process also helps maintain consistency in our code, making it easier to spot bugs early on and ensuring a higher level of confidence in the production deployment.

Benefits:

• Early Error Detection: TypeScript's type checking will be enforced during the build, catching errors early before code reaches production.
• Code Quality Assurance: Including the tsc task ensures that only type-safe code is included in production builds, reducing the likelihood of runtime type errors.
• Improved Developer Experience: Developers will be alerted to type issues during the build process, helping to maintain cleaner and more maintainable code.

Please review and provide feedback. Thank you!

[tnylea]

What would be the difference running npm run build && vite build --ssr vs vite build && vite build --ssr

LMK. Thanks.

[christophstockinger]

If you execute npm run build, npm run prebuild is automatically executed before the build.

[tnylea]

Aha, perfect. Thanks for letting me know.

[tnylea]

Hey @christophstockinger.

Thanks for the PR. So, if we add this as an NPM build step, why aren't you adding this to the CI workflow? Seems like if we are going to add it in, we might as well add it to the workflow file, right?

[christophstockinger]

Hey @christophstockinger.

Thanks for the PR. So, if we add this as an NPM build step, why aren't you adding this to the CI workflow? Seems like if we are going to add it in, we might as well add it to the workflow file, right?

More information you find here: https://docs.npmjs.com/cli/v8/using-npm/scripts

[JoeyMckenzie]

Is there any particular reason these declarations were included instead of the usual vite-env.d.ts like the original Breeze templates had? Something along the lines of:

/// <reference types="vite/client" />

interface ImportMetaEnv {
    readonly VITE_APP_NAME: string;
    [key: string]: string | boolean | undefined;
}

interface ImportMeta {
    readonly env: ImportMetaEnv;
    readonly glob: <T>(pattern: string) => Record<string, () => Promise<T>>;
}

within a resources/js/types/vite-env.d.ts file. I think this approach completely overrides anything declared in ImportMetaEnv and ImportMeta if it exists in vite/client, rather than merging it (like the above). I know this PR is just moving this bit to a separate file, so it might be a better question for @tnylea.

[christophstockinger]

@JoeyMckenzie I have just tried it out. You are right, the type declaration for vite/client is not needed. I have just adjusted the PR accordingly and removed it.

[tnylea]

Thanks, Christoph 👏

Will be doing some discussion with Taylor on this tomorrow, and we'll follow up. Appreciate it!