feat: change createMessagesDeclaration to also accept array for monorepo support #1700
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
@felix-quotez is attempting to deploy a commit to the next-intl Team on Vercel. A member of the Team first needs to authorize it. |
There was a problem hiding this comment.
Hey, thanks for proposing this PR!
I've left a note about keeping the previous API to keep the common case simpler, but I think it should be fine to extend this.
As a side note, can you share how you're importing messages from another repo? I know that other users have struggled with this: #1688. Might be worth verifying this works with the proposed changes.
| @@ -1,6 +1,6 @@ | |||
| export type PluginConfig = { | |||
| requestConfig?: string; | |||
| experimental?: { | |||
| createMessagesDeclaration?: string; | |||
| createMessagesDeclarations?: Array<string>; | |||
There was a problem hiding this comment.
Can we keep the existing signature to make the common case easy?
| createMessagesDeclarations?: Array<string>; | |
| /** A path to the messages file that you'd like to create a declaration for. In case you want to consider multiple files, you can pass an array of paths. */ | |
| createMessagesDeclaration?: string | Array<string>; |
|
Pushed a fix, the type is now "string | Array;" and the property continues to be called the singular "createMessagesDeclaration". Please have another look.
I have a special setup so I am not sure how helpful this is for others. It's for sure different from the linked discussion/request in that I enjoy that each app/package has their own messages. In my setup I am combining the @formatjs/cli for extracting messages with next-intl (the goal is to get the "colocation" benefit outlined here https://formatjs.github.io/docs/getting-started/message-declaration/). Using the CLI also nicely gives me an en.json file per package. In the request.ts file I need to manually import all the relevant messages file--it not ideal but also not too concerning to me. |
felix-quotez
changed the title
There was a problem hiding this comment.
Looks great, thanks a lot!
I enjoy that each app/package has their own messages
I'd do that to. Sorry, I just noticed I've linked to the wrong discussion, this one seems more related: #1224.
In my setup I am combining the @formatjs/cli for extracting messages with next-intl (the goal is to get the "colocation" benefit outlined here https://formatjs.github.io/docs/getting-started/message-declaration/).
What, really? 😄 Can you give an example how the usage of translations in a component looks like? Do you use defineMessages along with useTranslations from next-intl in a component?
|
Out in |
|
Thanks for merging the PR! 🥳
Yes, this is exactly what I do. (I simply re-exported these function from our internal package so that it looks good in the components, both, defineMessages and useTranslations are unchanged.) I am using a custom formatter, that takes the formatjs output, and formats in the way next-intl needs it. So it gives full type safety--and now also with type safe arguments thanks to your work! import { defineMessages } from '@tw/intl/define-messages'
import { useTranslations } from '@tw/intl/use-translations'
defineMessages({
propertyNameIsIgnoredInFavorOfIdBelow: {
id: 'a.b',
description: 'foo',
defaultMessage: 'bar',
},
})
export function Component() {
const t = useTranslations('a')
return t('b')
}Edit: The worst part about this is that the files need to be manually watch to trigger extracting message with formatjs. I don't think they support a "--watch" option. |
|
That's really interesting, thanks for sharing! |
Resolves: #1699
This change renames "createMessagesDeclaration" to "createMessagesDeclarations" and changes the type to an array. Each entry of the array will be used to create message declaration files. Supporting multiple message files helps to use next-intl in monorepo setups.
Since v4 is in beta, I renamed the property and removed support for a single string. To me, clean types lead to cleaner code. If compatibility is a more of a concern during the beta phase, I could not change the property name and keep the support for single strings. Please let me know.