Codecov Report

Merging #7430 into dev will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##              dev    #7430   +/-   ##
=======================================
  Coverage   70.26%   70.27%           
=======================================
  Files          88       88           
  Lines        3696     3697    +1     
  Branches     1008     1008           
=======================================
+ Hits         2597     2598    +1     
  Misses        892      892           
  Partials      207      207           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2e711c1...4029901. Read the comment docs.

I'm wondering if it's doing different things like what most framworks are doing, like babel won't have babel.config.js --falback-to--> .babelrc, eslint wont have .eslintrc.js --falback-to--> .eslintrc.

Indeed this is same behavior we will have. (both loaded) The current loadConfig fixture for nuxtrc does not have a nuxt.config.js file. Main different with other (js) frameworks, is that nuxtrc is flat INI that allows easy modifications by automated tools (even a bash script) but loaded as valid json.

Another point is : Regarding to use rc file, is there anything impossible or hard to be implemented by using nuxt.config.js (or maybe a global nuxt.config.js) ?

The most advantage is updating as for nuxt.config we need to parse syntax with different possibilities ({typescript, esm, cjs} x {exported object, exported function}) compared to a dead-simple syntax and using rc.update(). It also makes nuxt.config more readable by hiding tokens or configs like telemetry into a plain file. Another advantage is that this file can be optionally checked-in into a repository so based on project requirements can be gitignored or not.

So if we always respect nuxt.config.js, .nuxtrc and ~/.nuxtrc at same time, do we need to provide a way to at least disable ~/.nuxtrc in an app for edge cases ?

So if we always respect nuxt.config.js, .nuxtrc and ~/.nuxtrc at same time, do we need to provide a way to at least disable ~/.nuxtrc in an app for edge cases ?

Agree. If we find a valid problematic case can support CLI flag but I don't think it would be necessary for initial support. PS: nuxt.config always has most priority and overrides nuxtrc.