Adjust install generator for typescript setups

[Andy9822]

This PR updates the Inertia install generator to use vite_typescript_tag "application" instead of vite_javascript_tag on the application layout when the --typescript flag is passed.

Additionally, it renames the generated application.js file to application.ts to align with the expected TypeScript setup.

This ensures consistency with the rest of the setup—for example, the inertia entrypoint already uses vite_typescript_tag. It also prevents confusion or broken asset references if developers try to update the application layout based on the included comment suggesting the use of vite_typescript_tag:

<%= vite_javascript_tag 'application' %>
    <!--
      If using a TypeScript entrypoint file:
        vite_typescript_tag 'application'

      If using a .jsx or .tsx entrypoint, add the extension:
        vite_javascript_tag 'application.jsx'

      Visit the guide for more information: https://vite-ruby.netlify.app/guide/rails
    -->

If they do switch to vite_typescript_tag 'application', as per the generated comment above, the asset fetching will fail because we generated the file as application.js even though it's a Typescript setup

New behavior

Closes #218

[Andy9822]

If we can’t find the application_js_path, we skip making any changes.
This likely means the user has customized their setup or didn’t follow the full generator path — so we avoid modifying anything to prevent interfering with their configuration.

[Andy9822]

hey @bknoles, in case this PR looks good to you, could you help merging this?

I'm not so familiar with contributing to OSS so Im sorry for directly mentioning you, but Im not sure how to properly handle these cases when it comes down to opening a PR, assign or mention someone etc...

[BrandonShar]

Thanks for the PR @Andy9822 ! @skryukov knows the generators better than Brian and I so I'd like to give him a chance to weigh in.

[skryukov]

@Andy9822 thanks for the PR!

I wonder what happens if a user installs Inertia Rails into an existing app that already uses application.js without TypeScript? Perhaps we could move this logic to the Vite installation step to ensure safety.

[bknoles]

Yea, I'd say application.js isn't in the scope of Inertia Rails since it's created by Vite Ruby. If Vite Ruby offered a way to configure its install generator, then it'd be nice to use that, but it doesn't.

Since application.js is a dummy file, I think I'd be ok with Inertia Rails deleting it, if and only if it was created during the Inertia Rails installation process. (i.e. it didn't exist before we running the install generator). To @skryukov's point, we shouldn't tamper with a user's application.js file if it already existed before installing Inertia Rails.

[Andy9822]

@Andy9822 thanks for the PR!

I wonder what happens if a user installs Inertia Rails into an existing app that already uses application.js without TypeScript? Perhaps we could move this logic to the Vite installation step to ensure safety.

hmm, not sure Im following what issue you're pointing out here @skryukov 🤔

The code of this PR runs inside the install_typescript function, so the application.js would only be converted to application.ts when installing Inertia with TypeScript

I personally don’t think we need to take an "extreme" or so opinionated measure like deleting the application.js file if it’s generated by Inertia — as @bknoles suggested — since it’s actually a fine and useful part of the install command, which helps scaffold a basic structure for you. It’s similar to what you get when generating a new Rails app with its install command.

[skryukov]

hmm, not sure Im following what issue you're pointing out here @skryukov 🤔

I'm talking about a case when someone installs Inertia Rails on top of an existing application (not a rails new one) that uses Ruby Vite—in that case, we don't want to touch their files. So, I believe we should either do nothing or move this logic to the install_vite step.

[Andy9822]

hmm, not sure Im following what issue you're pointing out here @skryukov 🤔

I'm talking about a case when someone installs Inertia Rails on top of an existing application (not a rails new one) that uses Ruby Vite—in that case, we don't want to touch their files. So, I believe we should either do nothing or move this logic to the install_vite step.

oooh ok, you mean when > Vite < had been installed outside of the Inertia install generator, sorry I finally got what you meant!
I just pushed a commit with that new approach

[BrandonShar]

@skryukov this makes sense to me, does the change to the vite install section address your concern?