feature request - Tool to detect un used keys

[techo207]

Hello guys,
Amazing job, I love intlayer

I have multiple dictionaries files and it is getting harder to mantain
is there a tool or option to detect un used keys?

Thanks

[aymericzip]

Hey @techo207! Thanks for the support!

By default on Vite, and when using @intlayer/swc with Next.js, Intlayer automatically purges unused dictionaries. This is usually the main reason behind importing massive amounts of unused content.

As for checking whether each field is actually imported, there isn’t a tool for that yet, though I’m considering implementing it. I’m just not sure about the best approach. If you have any suggestions, you're welcome 😊

If you haven’t implemented it yet, I also recommend using dynamic imports to avoid unnecessary bundle size increases: Build configuration docs

[techo207]

I think the best approach is to only show a log with the dictionary key and unused property names, and let the developer handle them. It could be a CLI and/or a plugin. I am currently using TanStack Start, so a Vite plugin would be awesome. Also, there should be a way to mark properties as exempt from warnings, and the plugin could optionally stop the build process.

[nhuray]

That's definitely a must have feature because over time it's easy to have churn.

A nice approach would be do leverage Biome or ESLint for AST / CST parsing and have an option to fix the findings.
Something like:

• Check the dictionaries are used in the code:

bun run intlayer lint 

• Check the dictionaries are used in the code and clean them (remove in original content file)

bun run intlayer lint --fix

[aymericzip]

Hey @nhuray, @techo207,

Indeed,

The complexity lies in the fact that there is a many-to-many relationship between dictionaries and components (not to mention the concept of remote dictionaries linked to the CMS). To perform this AST-based check, we would therefore need to traverse all the components in the codebase (or store a mapping somewhere)

Intlayer also includes a transformation at build time. So in my opinion the best approach would be to filter out (or log) unused keys at that stage. However, I think the impact would be minimal, probably filtering out at most 5% of the total keys.

Although the feature is very interesting, I’m not prioritizing it given its complexity

But I’m open to any contribution, and I’d be happy to support the development if a volunteer is willing to dedicate the time to proposing a solution