Vite migration and dependency updates

[santiagoars]

Vite migration and dependency updates

## Description
With the latest update to @remix-run, the recommendation by the Remix team is to abandon the classic compiler (known as the remix compiler) in favor of adopting Vite. There's a full guide on all changes needed for the migration, which can be found in the following link: https://remix.run/docs/en/main/start/future-flags#adopt-the-vite-plugin

What changed

• We have now adopted the use of the Vite compiler, replacing the so called classic Remix compiler.
• Adopted all of the future flags described in the link above to make it easier when Remix v3 arrives.
• Removed the <LiveReload /> component from the root.tsx file.
• Updated the way we import CSS in the root.tsx file.
• Used the tsconfigPaths() plugin in vite to support the use of ~ in our file imports.
• For all <Link /> components, changed the route to include ../ at the beginning of a path.
• Updated the build, start and dev scripts in the package.json to use Vite.
• Created the postcss.config.mjs file to support the use of tailwind with Vite.
• Added changes in the doc to show the current terminal output when using Vite.

This PR also contains dependency updates for the following dependencies:

Package	Old Version	New Version
react-datepicker	7.3.0	7.5.0
eslint-plugin-tailwindcss	3.17.4	3.17.5
eslint-plugin-tsdoc	0.2.17	0.4.0
@remix-run/dev	2.13.1	2.15.2
@remix-run/node	2.13.1	2.15.2
@remix-run/react	2.13.1	2.15.2
@remix-run/serve	2.13.1	2.15.2
@mui/material	6.0.2	5.16.14
@mui/icons-material	6.0.2	5.16.14

One quick note on both of the mui dependencies. Although it appears we are downgrading, we can find that 5.16.14 is the latest release in their releases list: https://github.com/mui/material-ui/releases

Upgrading to any MUI version starting with a 6 ends with the project being riddled with hydration errors and breaking the whole thing. Once React v19.0.0 is compatible with Remix, we can upgrade to MUI 6.

Fixes # (issue number)

## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update

## How Has This Been Tested?

• Updated the dependencies listed above in the package.json file of the ords-remix-jwt-sample template.

• Generated a new project from that template.

• Executed the dev command of the project and confirmed that there were no import errors.

• Did a full scan of the project and confirmed that everything worked as expected.

  Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings/errors
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

[oiramS]

Looks good to me, I have a few request:

• Update the description of this MR to include a link to the adoption of the vite puglin guidelines and to describe exactly what changed in the project.

• Update the Start the dev server section of the readme to reflect the current behavior of the server.

I am not sure if we should bump the version of this template, lets have that discussion with Antonio once the requested changes are implemented.

Great job!

[oiramS]

LGTM!

[dbtools-antcampo]

I am not sure if we should bump the version of this template, lets have that discussion with Antonio once the requested changes are implemented.

@oiramS you mean the version in the package.json of the template? I think we shouldn't, that file will be used by devs to define the version of their application, which will probably start with 1.0.0.

[oiramS]

I am not sure if we should bump the version of this template, lets have that discussion with Antonio once the requested changes are implemented.

@oiramS you mean the version in the package.json of the template? I think we shouldn't, that file will be used by devs to define the version of their application, which will probably start with 1.0.0.

understood, lets keep it as 1.0.0