Hello,
Just as a reference for later since I didn't find one ticket dedicated to typescript.
Thanks.
Hi @Nelrohd! You can find some thoughts in #42 (there is currently a TS compatibility issue with what i18n.js exports)
As I've stated in various places, I prefer to have single issues for single bugs / feature requests. Let's discuss Typescript support here.
Thanks @Nelrohd, we're looking forward to your suggestions and assistance!
I locate this definition file in my project as the library is external module.
next-i18next.d.ts
// This did not work,so move the renewal code to latest post.
This can be applied with some modifications as internal modules' definition.
I think we can do it split this to dist/middleware/index.d.ts and next-i18next/index.d.ts and change declare to export .
I have not previously used Typescript on any significant projects, but will very soon be beginning professional work with it. I'd prefer to wait on this for awhile, and potentially properly convert the whole project.
Until then, if someone does want to create a PR with typings that does not affect any of the codebase, I'd happily accept it.
@tkow how does your export in the app's i18n.ts look like? The way this is done in example does not work well for me in TS projects:
https://github.com/isaachinman/next-i18next/blob/da40a3e7020613de5c2345adb871b4e556f16389/example/i18n.js#L3
https://github.com/isaachinman/next-i18next/blob/5913957ec0bb9e5d4bf495325d07b1143f0ab54b/example/pages/_app.js#L3
I have to do the following:
export const appWithTranslation = nextI18next.appWithTranslation;
import { appWithTranslation } from "../i18n";
Just bringing this up since this is related to the typings you're suggesting to add.
@kachkaev You're right. I modify the example in my project.
I set ~i18n/index.ts like this.
```typings/next-i18next.d.ts
import NextI18Next from 'next-i18next'
import nextI18NextMiddleware from 'next-i18next/middleware'
const options = {
defaultLanguage: 'ja'
}
export default i18n = new NextI18Next(options)
export {nextI18NextMiddleware}
export const withNamespaces = i18n.withNamespaces
export const Link = i18n.Link
export const Trans = i18n.Trans
export const appWithTranslation = i18n.appWithTranslation
export const config = i18n.config
```
I'm sorry for that, but as I see this stack overflow questions, it is though to bundle export modules to implement bundle export singleton properties now about esm module, though I found using import require solution but we decided to export singleton because our project have not afforded time to try this for next release.
I'm glad if these help you.
I apologize that middleware second argument is not next/app's App, so I modified above example as App is typeparameter.
I have found my .d.ts file wrong. This library are exported in commonjs modules and not using module.exports.default, thus we must import the way like
import * as NextI18Next from 'next-i18next';
or
with module.exports.default = NextI18Next
"allowSyntheticDefaultImports": true,
are needed about tsconfig.json and index.js.
So, above my .d.ts is not correct. Sorry for that and I'll try to fix it.
(Edit)
I surveyed about commonjs and esm, then I conclude that we may export esm format module from this library because I notice that nextjs may use AMD modules feature in next procedure. As I see it, the problem may be very complex. The reason why is "add-module-exports" babel plugins override default export to use module.exports thus we should use import Module = require('next-i18next') because this is ordinary commonjs format module, but nextjs needs esm module format to build. If import = require statement is used, server internal error occur and nextjs doesn't build files to destination directory. So though it is not recommended according to Definitely Typed team conclusion (see common mistakes) and this so question, we can achive to adapt commonjs to esm format like this type definition and initialize file with adding redundant namespace definition. Total files bellow,
```typescript:~/i18n.ts
import * as NextI18Next from 'next-i18next'
import * as nextI18NextMiddleware from 'next-i18next/middleware'
const options = {
defaultLanguage: 'ja'
}
export default new NextI18Next(options)
`
```typescript:next-i18next.d.ts
type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>
declare module 'next-i18next' {
import {ComponentType, ReactNode} from 'react'
import {Trans,withNamespaces} from 'react-i18next'
import App from 'next/app'
interface Config {
defaultLanguage: string
otherLanguages: string[]
preload: string[]
fallbackLng: string|null
load: string
localePath: string
localeStructure: string
localeSubpaths: boolean
ns: string[]
use: any[]
interpolation: {
escapeValue: boolean
formatSeparator: string
format(value:string, format:string):string
},
browserLanguageDetection: boolean
ignoreRoutes: string[]
detection: {
order: string[]
caches: string[]
}
backend: {
loadPath: string
addPath: string
}
react: {
wait: boolean
}
}
type UserConfig = Omit<Partial<Config>,'ns'|'backend'|'preload'>
interface LinkProps {
as?: string
children: ReactNode
href: string
}
namespace NextI18Next {
}
class NextI18Next {
constructor(userConfig:UserConfig);
appWithTranslation<Props=any>(WrappedComponent:App<Props>):App<Props>;
appWithTranslation<Props=any>(WrappedComponent:ComponentType<Props>):ComponentType<Props>;
withNamespaces: typeof withNamespaces
config: Config
Trans: typeof Trans
Link: ComponentType<LinkProps>
}
export = NextI18Next
}
declare module 'next-i18next/middleware' {
import NextI18Next from 'next-i18next'
namespace nextI18NextMiddleware {}
function nextI18NextMiddleware <Server=any,App = any>(nexti18next:NextI18Next, app:App, server:Server):void;
export = nextI18NextMiddleware
}
This is remedy so, I want you export esm style modules, and add package.json module option with specified esm path, it may adapt nextjs structure.
Hi @tkow, c424b06 should fix that import issue.
I briefly started to look into TypeScript conversion on a branch called typescript-conversion. As expected it's going to be a relatively lengthy process to get all the types laid out and working nicely together. Some of the approaches currently taken may need to be completely rethought out as well.
If anyone feels like championing this effort, I can provide collaborator access. Otherwise I'll handle this myself slowly over several weeks.
I would love to learn some TypeScript, but would be starting at the ground floor (as in I have programmed in typed languages before C/C++/Java, but never TypeScript) and, so, probably am not the best person to champion this effort. I'm more than willing to help out, though.
I'm rethinking if this is appropriate prior to a 1.0 release. We've got a lot else going on at the moment, and a TypeScript rewrite is going to be a very intensive activity. I'll post in this thread when I have updates.
Most helpful comment
I'm rethinking if this is appropriate prior to a 1.0 release. We've got a lot else going on at the moment, and a TypeScript rewrite is going to be a very intensive activity. I'll post in this thread when I have updates.