[bug] Message IDs clashing with internal variables

[4kimov]

Problem

When using "@inlang/paraglide-js": "1.0.0-prerelease.20" and having translations for Bahasa Indonesia, whose language id is "id", the following bug appears:

Uncaught (in promise) SyntaxError: Identifier 'id' has already been declared

On this line (from what I understand is an internally generated function):

export const id = (params = {}, options = {}) => {

Expected behavior

The error should not happen.

Reproduction

Create a messages/id.json file.

Other information

No response

[samuelstroschein]

@LorisSigrist I think this relates to index functions for the languages. Nasty edge case.

[LorisSigrist]

On it!
We should probably have an e2e test with all languages

[LorisSigrist]

This isn't an indonesia-specific edge case. This happens whenever there is a message that shares a name with a language tag.

The import import * as id from "./messages/id.js" is conflicting with the message function export const id = () => { ... }. The solution is to use unique aliases for the language namespaces. Eg import * as paraglide_language_id_297834 from "./messages/id.js".

The same issue would happen if the ID "languageTag" were to be used.
i propose we add unique hashes to any internal variable names so that they will never conflict with any message IDs

[samuelstroschein]

@LorisSigrist can you make a loom? The issue is a bit abstract to follow

[LorisSigrist]

https://www.loom.com/share/efc78b2a571f454c8edd76e149c528a3

[LorisSigrist]

Alternatively, we could also keep the names of the internal and instead give the message functions random names, and then only export them at the very end. This would keep the interface a little prettier since we wouldn't need to rename params & options.

Eg:

import * as id from "./messages/id.js"

const id_2374865 = (params, options) => {
   ...
}

const other_message_30981 = (params, options) => {
   ...
}


export { 
  id_2374865 as id, 
  other_message_30981 as other_message  
};

Once the random-id proposal hits this will be much less of an issue

[samuelstroschein]

@LorisSigrist I don't understand why params and options need to be renamed. They are scoped variables.

Generally, this seems like a non-issue. Don't name your messages like language tags and the problem is gone. #1892 will further strengthen this. The downsides of hashing stuff that come to mind:

• less human readable (minor)
• larger bundle size (major)

@4kimov can you confirm that the bug was triggered because you named a message "id"?

[4kimov]

@samuelstroschein Yes, I saw the error when I created the file messages/id.json.

Edit: I'm assuming by "message" you mean the filename. Inside that JSON file, I also have the key by the name id, with its own translation.

[samuelstroschein]

I also have the key by the name id, with its own translation.

That is the root cause. Don't name your key like a language tag.

The issue is so rare that we will likely not implement logic (which adds complexity) to solve this issue. Besides, we will introduce automatically generated names to avoid issues like these and increase the DX with #1892.

[4kimov]

Ah, I didn't know that. Ok thank you for the heads up!