Recommendation for ESLint Globals with Nuxt
Working on setting up ESLint for a nuxt project. Had an old version and migrated to ESLint 9 with the new flat config. I integrated prettier and used Nuxt ESLint.
Nuxt ESLint mentions that it is project-aware flat config that I can then add to. This is set up with
export default with Nuxt which I did. I was hoping this would fix ESLint complaining about things built into Nuxt, and globally available not being defined such as $nuxt, $fetch, etc as well as potentially my composables that are exported and globally available. It looks to have addressed some such as $nuxt and $fetch, so I no longer have to list those in the languageOptions, globals of my eslint.config.mjs. But several things such as useCookie, useFetch, navigateTo, useRuntimeConfig are still not defined and give an error on linting, same with all of my composable functions.
Is there a better way to handle this or do you have to just add everything you want defined in the ESLint or manually import each of these things into each .vue file that is using them?4 Replies
Hi @Mightsrain. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
You're correct that the Nuxt ESLint module provides a project-aware flat config, which should automatically recognize many of Nuxt's built-in globals and composables (like $nuxt, $fetch, etc.), so you don't need to manually declare them in your ESLint config. This is one of the main benefits of using the Nuxt ESLint module with the new flat config format—it is designed to reduce the need for manual global declarations and to work seamlessly with Nuxt's auto-imported APIs and composables ESLint Module Code Style.
However, if you are still seeing ESLint errors for some Nuxt composables (such as useCookie, useFetch, navigateTo, useRuntimeConfig) or your own custom composables, this is a known limitation: ESLint itself does not have awareness of Nuxt's auto-imports for custom composables or for every possible Nuxt composable out of the box. The Nuxt ESLint config covers the most common built-ins, but not custom ones or every possible helper.
Current best practices based on the knowledge sources:
- Nuxt built-in composables: Most should be recognized by the Nuxt ESLint module, but if some are not, you may need to add them to the
- Nuxt ESLint module covers most built-ins, but not all. - For missing built-ins or custom composables, add them to
globals section of your ESLint config as a workaround.
- Custom composables: ESLint cannot automatically know about your custom auto-imported composables. You will need to either:
- Add them to the globals in your ESLint config, or
- Manually import them in each file where they are used.
There is no mention in the official documentation of a fully automated way for ESLint to recognize all custom auto-imported composables in Nuxt 3. The recommended approach is to use the Nuxt ESLint module for built-ins and supplement with manual globals for your own composables as needed ESLint Module Code Style.
Example: Adding globals in eslint.config.mjs
Or, you can continue to manually import your composables in each file.
Summary:- Nuxt ESLint module covers most built-ins, but not all. - For missing built-ins or custom composables, add them to
globals or import them manually.
- There is no fully automated solution for custom composables in the current Nuxt/ESLint ecosystem.
If future updates to the Nuxt ESLint module or ESLint itself provide a more automated solution, it will likely be documented in the Nuxt ESLint documentation.
Let me know if you need an example config or further clarification!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@231825416317304832> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
My current
eslint.config.mjs file,
Another example is that I define my emits, and then componenets in the page emit them.
So in <script setup>,
something like,
const emits = defineEmites(["toggleVisible"]);
and then in one of the components in that page,
@update:visible="$emit('toggleVisible', false)"
So I define the emit in the emits section, (which if I remember right is required and will break if you don't) and then I use the emit within the component. But then the linter complains about it not being used.
Is there a way to avoid this issue too, or do I just have to add an inline ignore to each of my emits that isn't used within <script setup> and is only used in a component?You don't have to assign your defineEmits to a variable.