Vite, TypeScript and ESLint updates and housekeeping

[devmount]

What changed?

This change maintains package dependencies. In particular, the following packages got a major upgrade:

• Vite to v8 (this is now done in Vite v8 upgrade #292)
• TypeScript to v6
• ESLint to v10

All other packages got minor or patch updates. eslint-plugin-import got removed (imho not needed anymore and incompatible to ES 10).

Furthermore, the tsconfig* files were changed to their common default values for migration purposes to TS 6. Please review that carefully and let me know, if I missed something here.

Also type errors were fixed and linting issues. All changes were kept at minor level, no breaking change was introduced intentionally.

All changes were tested. Linting, Building and Storybook work as intended locally for me. But please test and confirm this.

Applicable Issues

Fixes https://github.com/thunderbird/services-ui/security/dependabot/54, https://github.com/thunderbird/services-ui/security/dependabot/55 and https://github.com/thunderbird/services-ui/security/dependabot/56

Closes #273

[davinotdavid]

Commenting only for now as I am not super familiar with the history / reason of our configs.

I think I need to read a bit more about the tsconfig / vite config options as I am not entirely sure why we need all the config we currently use but also running npm run build outputs this in my machine:

❯ npm run build

> @thunderbirdops/services-ui@1.6.2 build
> vite build --

vite v8.0.11 building client environment for production...
✓ 126 modules transformed.

[unplugin:dts] Start generate declaration files...
[unplugin:dts] Start bundling declaration files...

[unplugin:dts] Failed to load '@microsoft/api-extractor', have you installed it?


[unplugin:dts] Error occurred, skip bundle declaration files.

[unplugin:dts] Declaration files built in 1089ms.

I seems to still produce an output but again I wonder if we can simplify our setup further so we can have more smoother dependency package updates in the future.

[devmount]

but also running npm run build outputs this in my machine:

Thanks so much for this catch. Should be fixed now. I reverted some of the changes and set bundleTypes to its initial value. The build process should work now without issues.

I wonder if we can simplify our setup further so we can have more smoother dependency package updates in the future.

Yes, I would appreciate this. However, splitting tsconfig into main, app and node seems to be the recommended way 🤔 At least this is what vue-create and other project init processes generate.

@MelissaAutumn Do you have any input on this?

---

Edit: Improving / Reducing the config files can be moved to another ticket imho.

[davinotdavid]

Thank you so much for this work! It mostly looks good to me except two points:

Somehow when I run npm run build I get these too:

src/components/BrandButton.vue:7:26 - error TS7022: 'name' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.

7     <template v-for="(_, name) in $slots" v-slot:[name]="slotData">
                           ~~~~
src/components/DangerButton.vue:7:26 - error TS7022: 'name' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.

7     <template v-for="(_, name) in $slots" v-slot:[name]="slotData">
                           ~~~~
src/components/LinkButton.vue:7:26 - error TS7022: 'name' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.

7     <template v-for="(_, name) in $slots" v-slot:[name]="slotData">
                           ~~~~
src/components/PrimaryButton.vue:7:26 - error TS7022: 'name' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer.

7     <template v-for="(_, name) in $slots" v-slot:[name]="slotData">
                           ~~~~

[davinotdavid]

Hmmm when I try to do npm i I have some peer dependency warnings:

npm warn ERESOLVE overriding peer dependency
npm warn While resolving: unplugin-dts@1.0.2
npm warn Found: @vue/language-core@2.2.12
npm warn node_modules/@vue/language-core
npm warn   @vue/language-core@"2.2.12" from vue-component-meta@2.2.12
npm warn   node_modules/vue-component-meta
npm warn     vue-component-meta@"^2.0.0" from @storybook/vue3-vite@10.4.1
npm warn     node_modules/@storybook/vue3-vite
npm warn
npm warn Could not resolve dependency:
npm warn peerOptional @vue/language-core@"~3.1.5" from unplugin-dts@1.0.2
npm warn node_modules/unplugin-dts
npm warn   unplugin-dts@"1.0.2" from vite-plugin-dts@5.0.2
npm warn   node_modules/vite-plugin-dts
npm warn
npm warn Conflicting peer dependency: @vue/language-core@3.1.8
npm warn node_modules/@vue/language-core
npm warn   peerOptional @vue/language-core@"~3.1.5" from unplugin-dts@1.0.2
npm warn   node_modules/unplugin-dts
npm warn     unplugin-dts@"1.0.2" from vite-plugin-dts@5.0.2
npm warn     node_modules/vite-plugin-dts

These seem to get resolved if I downgrade this to 4.5.4 instead.

[devmount]

Good catch. Apparently vite-plugin-dts evolved to the unplugin-dts package in the meantime. But switching those won't change anything, since the former is just a wrapper for the Vite part of the latter now.

The error TS7022 you found above only happens when downgrading this to 4.5.4. It is fixed in versions 1.0.0-beta.3 and above, but those version then have the conflicting dependency.

So how do we want to solve this? I suggest for now, we downgrade to 4.5.4 and ignore the 4 TS7022 false positives. Or what do you think?

[davinotdavid]

Hmm I wonder if the peer dependency problem will be fixed upstream soon-ish. I don't think we should be ignoring false positives unless there's a big positive / reason in upgrading.

Keeping packages updates with the latest is nice but we don't currently have security vulnerabilities as of now so maybe we should lean towards stability vs bleeding edge IMHO

I'd say that we can keep the issue / PR open for now though so we can remember of checking this in the near future.

[devmount]

Making this draft again, that we don't accidentally merge this in. We wait on package updates that the peer dependency conflicts get resolved.

[MelissaAutumn]

Sorry I missed this discussion. I'm not entirely caught up on the latest node package standards, but I would think projects split up tsconfigs into multiple parts is for cli, frontend, and server-side rendered configs.

Otherwise I think we should maybe split this PR up so we can merge the Vite 8 upgrade separately.

[devmount]

@MelissaAutumn Thanks, good idea! Let's do the Vite 8 update separately 👍🏻

Edit: Did that in #292