Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better typescript support #60

Open
jarda-svoboda opened this issue Apr 17, 2022 · 3 comments
Open

Better typescript support #60

jarda-svoboda opened this issue Apr 17, 2022 · 3 comments
Labels
base Issue related to base functionality enhancement New feature or request parsers Issue related to message parsers typescript Issue related to type definitions
Milestone

Comments

@jarda-svoboda
Copy link
Member

jarda-svoboda commented Apr 17, 2022

Currently, there is no type checking for translation keys, which can result in typos. Also payload types have to be defined manually and options contain all definitions for all modifiers at once.

sveltekit-i18n should provide a plugin/CLI based way how to deal with that, fetching sources and generating appropriate types automatically. payload and options types should be inferred from translations dynamically according to specified key.

@jarda-svoboda jarda-svoboda added enhancement New feature or request parsers Issue related to message parsers base Issue related to base functionality labels Apr 17, 2022
@jarda-svoboda jarda-svoboda added this to the 3.x milestone Apr 17, 2022
@jarda-svoboda jarda-svoboda added the typescript Issue related to type definitions label May 4, 2022
@bartduisters
Copy link
Contributor

An example to get rid of the TypeScript warning in the template.

<div>{@html $t('common.some-key', { link: 'https://code-coaching.dev' })}</div>

👆 This would show a TypeScript error on the link: 'some string' part.

👇 This is the manual definition that @jarda-svoboda is talking about.

import type { Config } from 'sveltekit-i18n';
import i18n from 'sveltekit-i18n';

interface Params {
  link: string;
  // add more parameters that are used here
}

const config: Config<Params> = ({
  loaders: [
    {
      locale: 'en',
      key: 'common',
      loader: async () => (
        await import('./en/common.json')
      ).default,
    },
    {
      locale: 'nl',
      key: 'common',
      loader: async () => (
        await import('./nl/common.json')
      ).default,
    },
  ],
});

export const { t, locale, locales, loading, loadTranslations } = new i18n(config);

@boian-ivanov
Copy link

I've been having this issue with a @ts-ignore bandaid for quite a while, until today where I started searching if we can modify the PayloadDefault, but this has helped immensely. Thanks @bartduisters! 👏
Although to be fair, I'm not sure how good that is, especially in bigger projects, where you might have a list of 100+ params that you may need to use. I'd be curious if it's even worth having that sort of type def, especially this deep, or potentially a way to set the type upon usage of the $t() function. Not really sure how, but an improvement on it might be needed.

@MaxSvargal
Copy link

It's good to have generated typings for each intl mesage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
base Issue related to base functionality enhancement New feature or request parsers Issue related to message parsers typescript Issue related to type definitions
Projects
None yet
Development

No branches or pull requests

4 participants