feat(vue): add typescript support

[reslear]

resolve: #1794

hi @jackocnr pls review :)

Changes:

• Typed input-props and options

• both components types support:

  import IntlTelInputWithUtils from 'intl-tel-input/vueWithUtils'
  import IntlTelInput from 'intl-tel-input/vue'

• exportable SomeOptions not necessarily, but maybe in the future:

  import { type SomeOptions } from 'intl-tel-input/vue'

• use modelValue instead value for v-model

• used vite multiple entries instead double run vite with custom configs.

TODO on future:

• use pnpm with worksapces, and move build data to shared package instead symlinks.
• use better build system instead grunt e.g zx
• need repo convert to monorepo (for clean installations for different frameworks, better ts support).
• think about improved logic for importing “utils”
• rename /vueWithUtils -> kebab-case e.g /vue-with-utils

[reslear]

hi @jackocnr friendly ping :)

[jackocnr]

This looks amazing, thank you so much!

A few questions/comments:

• I think we need to include the vue/build/ directory in git, so people can consume this component - this is how the main plugin and the react component work. Do you agree, or am I missing something?
• Why the move from vue/src/intl-tel-input/IntlTelInput.vue to vue/src/IntlTelInput.vue? My concern is that this will mess with the module names in vue/build/exports/IntlTelInput.d.ts but I can't yet see that file to check this. (e.g. we found that with the React component, we needed to have the intl-tel-input/ directory so that the react component's TS module name was "intl-tel-input/react" - see here, which matches how the react component gets imported when people use this library and hence the types get applied correctly)
• Why the move from vue/build/IntlTelInput.mjs to vue/build/exports/IntlTelInput.mjs? It seems like an unnecessary step to me and makes it less consistent. But if there's a good reason e.g. if this is an unavoidable Vue thing, then I can accept it.

Again, thank you so much for this great work 💐

[reslear]

1. And in reality do we need data that is compiled I think not, if you analyze popular packages, For vue we don't to have the compiled version if we need it, we have npm code or just go to node_modules/.
   I don't look at compiled code unless I need to patch it.

2. to generate types we need an input file .ts/.js where .vue components should be imported. Folder exports i'ts a normal practise e.g..

The problem is that the file and category names are the same, which may cause conflicts.
but I can check again.
Let me take another look at it. If we can keep it without moving it, I might do that.

what about TODO on future:?

[jackocnr]

Re: providing build files, I suppose we don't need to provide build files in the standard case e.g. if your project uses a build tool that supports TypeScript you can just import the Vue src file. The problem is for someone who is not using TS, and doesn't support it in their current build setup - how will they import the component? Or am I overthinking this? Do all Vue bundlers/build tools support TS by default?

Re: the exports section in package.json, now I'm wondering: what's the point in adding the build paths here, when we don't provide those build files when the package is consumed? Again, I fear I'm missing something here - my understanding of these things might be flawed or out of date - if that's the case, forgive me!

Re: future TODOs - I'm open to all of these ideas, but can you help me understand the benefits of each one? Perhaps it's better to discuss these ideas separately.

Thanks again.

[reslear]

Re: providing build files, I suppose we don't need to provide build files in the standard case e.g. if your project uses a build tool that supports TypeScript you can just import the Vue src file. The problem is for someone who is not using TS, and doesn't support it in their current build setup - how will they import the component? Or am I overthinking this? Do all Vue bundlers/build tools support TS by default?

but we build this before publishing and end up with pure js with no typscript only .d.ts types but next to the js files

Re: the exports section in package.json, now I'm wondering: what's the point in adding the build paths here, when we don't provide those build files when the package is consumed? Again, I fear I'm missing something here - my understanding of these things might be flawed or out of date - if that's the case, forgive me!

exports it is just a wrapper for vue or more specifically for the d.ts plugin which needs an input file, it is just a feature of building with this solution.
However, I will reconsider

[jackocnr]

I would really love to get this merged, but sadly don't know anything about Vue. Perhaps our beloved Vue team could offer their opinions on how to get this over the line? @carlssonemil @joaovinicius @mdpoulter @bettysteger 🙏🏻

[carlssonemil]

As I rarely use TypeScript (we don't use it at work), take my opinion with a grain of salt.

I don't see any big issues with this, other than what you two have already discussed regarding the potential conflict with the module names. It will in the end modernize the library and add type-safe exports for the Vue component.

As long as we can make sure that it does not mess with the module name and the exports are accessible after importing the component, we should be good. We probably also need to update the documentation to reflect these changes.

• need repo convert to monorepo (for clean installations for different frameworks, better ts support).

This would probably help a lot with separating the code bases and make it easier to maintain a specific framework. But, it might also add a lot of unwanted overhead when maintaining 🤷

If you're hesitant with the file re-structure, which is warranted, it's entirely up to you if you want to go forward with these changes. As someone that does not really need TypeScript in this package, I don't really mind whichever way you decide to go 😁

[carlssonemil]

This change is good, but I'm pretty sure it will be a breaking change since you would now need to pass your local value with the v-model attribute rather than the value attribute. So everyone updating to this version will need to update their value handling.

<!-- Current value handling -->
<IntlTelInput :value="localValue" />

<!-- Updated value handling with these changes -->
<IntlTelInput v-model="localValue" />

I'd much rather we do this more gracefully. For example, we can still do this change, but we keep the value prop and set the number to whichever prop (v-model or value) contains a value. And then plan to deprecate the value prop later on. Or, we just do this change and document it as a breaking change in the release notes.

[jackocnr]

Thanks for spotting this. I've since taken @reslear's commit, rebased it on master, added a couple of fixes, and pushed it to a new branch called vue-ts. Is there any chance you would be up for making this change you're proposing, to prevent this from being a breaking change, and creating a PR to push it to that branch? Then I think we can release this!

[carlssonemil]

Thanks for spotting this. I've since taken @reslear's commit, rebased it on master, added a couple of fixes, and pushed it to a new branch called vue-ts. Is there any chance you would be up for making this change you're proposing, to prevent this from being a breaking change, and creating a PR to push it to that branch? Then I think we can release this!

Definitely! I'll see if I can find the time this week to put up a PR!

[jackocnr]

By the way, if there is an option to simply undo this change to get this TS support merged, then that'd be fine with me as well! Then we can think about re-adding it in the next major release. I'm not sure if that's possible tho... I'll leave it to you!

[jackocnr]

Also, I've pushed a few fixes to master - do you mind if I rebase the vue-ts branch and force push? I don't want to complicate things if you're already working on this?

[carlssonemil]

I haven't found the time to start yet, so feel free to rebase! I'll do my best to get it done in the coming days!

[jackocnr]

I've just force pushed 👍🏻

[jackocnr]

Thanks so much for your thoughts here @carlssonemil 💐

As long as we can make sure that it does not mess with the module name and the exports are accessible after importing the component, we should be good

After reflecting on this a bit longer, I think this will all be fine TBH. I say let's get this merged, as long as we can make it a non-breaking change for now (see my other comment).

[reslear]

do you need help from me?

[carlssonemil]

do you need help from me?

If you feel like you have the time, then yes! I'm completely swamped with work this week. It should be a pretty easy change, just make sure you define the local v-model value so that it supports both the modelValue prop and the value prop.

[jackocnr]

Please be sure to rebase when you make any changes, as I've since deleted all build files from the project.

[carlssonemil]

I sincerely apologize for not fixing the v-model thingy yet. I'm still swamped at work with an upcoming release that is taking up all my time and energy.

[jackocnr]

Hi guys, thanks for your work on this, I've already merged this into my new v26 branch, hoping to release soon! I'll post here when I do.

[jackocnr]

Released in v26.0.0-beta.0 - @carlssonemil @reslear please try importing this version into your projects and test if the TypeScript types work 🤞🏻 (please see the list of breaking changes in this release in the linked release notes)

[jackocnr]

Hi @reslear, I'm not familiar with Vue myself, but I've just created a new test project with create-vue, with typescript support, and imported this component, and the type checking worked, which is great news!

With that said, I found a couple of things that didn't work, e.g. I could set the initialCountry option to an invalid country code like "gbbb" and it didn't give an error. Or if I use the i18n option, I could pass invalid translation keys without seeing an error. I looked in the type definition files, and they seem to have broken links to intl-tel-input/data and files in intl-tel-input/i18n/ which I then traced back to these exclude lines.

I've just done a test and commented out (all of) these excludes, and released that as v26.0.0-beta.1, and that fixes the issues for me (I now get a TS error if I try to use an invalid country code or translation key). But I just wanted to check in with you about this change - was there a reason for excluding these files in the first place?