Ficheiro de Configuração da Nuxt
Por predefinição, a Nuxt está configurada para cobrir a maioria dos casos de uso. Esta configuração predefinida pode ser sobrescrita com o ficheiro de nuxt.config.js.
nuxt.config.js 
alias 
Esta opção permite-nos definir pseudónimos que estarão disponíveis no nosso código de JavaScript e CSS:
import { resolve } from 'path'
export default {
  alias: {
    'style': resolve(__dirname, './assets/style')
  }
}
 alias .build 
Esta opção permite-nos configurar várias definições para o passo de build, incluindo loaders, filenames, a configuração da webpack e transpilation:
export default {
  build: {
    /*
     ** Podemos estender a configuração da
     ** webpack neste contexto.
     */
    extend(config, ctx) {}
  }
}
 build .css 
Esta opção permite-nos definir os ficheiros de folha de estilo em cascata, módulos e bibliotecas que queremos incluir globalmente (em todas as páginas):
export default {
  css: ['~/assets/css/main.css', '~/assets/css/animations.scss']
}
 Podemos omitir a extensão do ficheiro para todos os ficheiros de folha de estilo, tais como .css, sass,.scss, .postcss, .less, .stylus, .styl, e outros, listados no vetor css no nosso ficheiro de configuração da Nuxt:
export default {
  css: ['~/assets/css/main', '~/assets/css/animations']
}
 Ao omitir a extensão, se tivermos um ficheiro de folha de estilo em cascata com a extensão .css e decidirmos mudar para usar .sass ou .scss, por exemplo, não teremos de atualizar o nosso nuxt.config, porque este usará a nova extensão, uma vez que o nome do ficheiro permanece o mesmo.
css .dev 
Esta opção permite-nos definir o modo development ou production da Nuxt (importante quando usamos a Nuxt programaticamente):
export default {
  dev: process.env.NODE_ENV !== 'production'
}
 dev .env 
Esta opção permite-nos definir variáveis de ambientes necessárias em tempo de construção (ao invés de definirmos em tempo de execução) como NODE_ENV=staging ou VERSION=1.2.3. No entanto, para variáveis de ambiente de tempo de execução a runtimeConfig é obrigatória:
export default {
  env: {
    baseURL: process.env.BASE_URL
  }
}
 runtimeConfig 
A configuração de tempo de execução tem suporte embutido de dotenv  para melhor segurança e desenvolvimento mais rápido. A configuração de tempo de execução é adicionada à carga útil da Nuxt, pelo que não é necessário reconstruir para atualizar a configuração de tempo de execução quando se trabalha em desenvolvimento ou com aplicações interpretadas do lado do servidor ou interpretadas apenas do lado do cliente. (No caso dos sítios estáticos, continuaremos a ter de regerar o nosso sítio para ver as alterações).
Suporte ao .env 
Se tivermos um ficheiro .env no diretório raiz do nosso projeto, este será carregado automaticamente em process.env e acessível dentro do nosso nuxt.config ou do serverMiddleware e quaisquer outros ficheiros que estes importem.
Podemos personalizar o caminho utilizando --dotenv <file> ou desativar completamente com --dotenv false. Por exemplo, podemos especificar um ficheiro .env diferente nos ambientes de produção, preparação (ou testes), ou desenvolvimento.
publicRuntimeConfig 
- deve conter todas as variáveis de ambiente públicas, uma vez que estas serão expostas no frontend. Isto pode incluir uma referência ao nosso endereço público de localização de recurso, por exemplo.
 - 
está disponível ao usar 
$configtanto no servidor como no cliente. 
export default {
  publicRuntimeConfig: {
    baseURL: process.env.BASE_URL || 'https://v2.nuxt.com'
  }
}
 privateRuntimeConfig 
- deve conter todas as variáveis de ambiente privadas e que não devem ser expostas no frontend. Isto pode incluir uma referências aos símbolos secretos da nossa interface de programação de aplicação, por exemplo.
 - 
só está disponível no servidor com uso da mesma 
$config(sobrepõe apublicRuntimeConfig). 
export default {
  privateRuntimeConfig: {
    apiSecret: process.env.API_SECRET
  }
}
 Usar os Nossos Valores de Configuração:
Podemos então acessar estes valores em qualquer lugar ao usar o contexto nas nossas páginas, no armazém de estado, componentes e extensões ao usar this.$config ou context.$config:
<script>
  asyncData ({ $config: { baseURL } }) {
    const posts = await fetch(`${baseURL}/posts`)
      .then(res => res.json())
  }
</script>
 Dentro dos nossos modelos de marcação de hipertexto, podemos acessar as nossas configurações de tempo de execução diretamente ao usar $config.*:
<template>
  <p>Our Url is: {{ $config.baseURL}}</p>
</template>
 $config fora de um contexto exclusivo de servidor (por exemplo, se utilizarmos $config em fetch, asyncData ou diretamente dentro do nosso modelo de marcação de hipertexto).runtimeConfig .@nuxtjs/dotenv para runtimeConfig .env .generate 
Esta opção permite-nos definir valores de parâmetros para cada rota dinâmica da nossa aplicação que será transformada em ficheiros .html pela Nuxt:
export default {
  generate: {
    // `gh_pages/` em vez de `dist/`
    dir: 'gh_pages',
    // Os ficheiros `.html` são gerados de acordo o caminho da rota.
    subFolders: false
  }
}
 generate .head 
Esta opção permite-nos definir todos os meta-marcadores predefinidos para a nossa aplicação:
export default {
    head: {
    title: 'my title',
    meta: [
      { charset: 'utf-8' },
            .....
        ]
    }
}
 head .loading 
Esta opção permite-nos personalizar o componente de carregamento que a Nuxt utiliza por predefinição:
export default {
  loading: {
    color: '#fff'
  }
}
 modules 
Com esta opção, podemos adicionar módulos de Nuxt ao nosso projeto:
export default {
  modules: ['@nuxtjs/axios']
}
 modules .modulesDir 
A propriedade modelsDir é usada para definir os diretórios dos módulos para a resolução de caminhos. Por exemplo: resolveLoading, nodeExternals e postcss da Webpack. O caminho de configuração é relativo a options.rootDir (predefinida como: process.cwd()):
export default {
  modulesDir: ['../../node_modules']
}
 A definição deste campo pode ser necessária se o nosso projeto estiver organizado como um mono-repositório do tipo de espaço de trabalho da Yarn.
moduleDir .plugins 
Esta opção permite-nos definir extensões de JavaScript que devem ser executadas antes de instanciar a aplicação de Vue.js raiz:
export default {
  plugins: ['~/plugins/url-helpers.js']
}
 plugins .router 
Com a opção router, podemos sobrescrever a configuração da Vue Router predefinida pela Nuxt:
export default {
  router: {
    linkExactActiveClass: 'text-primary'
  }
}
 router .server 
Esta opção permite-nos configurar as variáveis de conexão para a instância do servidor da nossa aplicação de Nuxt:
import path from 'path'
import fs from 'fs'
export default {
  server: {
    https: {
      key: fs.readFileSync(path.resolve(__dirname, 'server.key')),
      cert: fs.readFileSync(path.resolve(__dirname, 'server.crt'))
    }
  }
}
 server .srcDir 
Esta opção permite-nos definir o diretório de origem da nossa aplicação de Nuxt:
export default {
  srcDir: 'client/'
}
 Exemplo de estrutura de projeto com a nossa aplicação de Nuxt no diretório client:
**-| app/
---| node_modules/
---| nuxt.config.js
---| package.json
---| client/
------| assets/
------| components/
------| layouts/
------| middleware/
------| pages/
------| plugins/
------| static/
------| store/**
 dir 
Esta opção permite-nos definir nomes personalizados para os nossos diretórios da Nuxt:
export default {
  dir: {
    // A Nuxt procurará a pasta `views` em vez da pasta `pages`.
    pages: 'views'
  }
}
 dir .pageTransition 
Esta opção permite-nos definir as propriedades predefinidas das transições de página:
export default {
  pageTransition: 'page'
}
 transition .Outros Ficheiros de Configuração
Para além do nuxt.config.js podem existir outros ficheiros de configuração na raiz do nosso projeto, tais como .eslintrc , prettier.config.json  ou .gitignore . Estes são utilizados para configurar outras ferramentas como o nosso analisador de qualidade de código (conhecido como linter) ou o nosso repositório de git e separados do nuxt.config.js.
.gitignore 
No nosso ficheiro .gitignore, teremos de adicionar o seguinte para serem ignorados e não serem adicionados ao controlo de versões. node_modules que é onde estão todos o nossos módulos instalados. A pasta nuxt que é a que é criada quando se executa os comandos de desenvolvimento (dev) ou construção (build). A pasta dist é a pasta que é criada ao executar o comando geração (generate):
node_modules .nuxt dist
 O Que Se Segue?
 
        Sébastien Chopin
       
 
        Nazaré da Piedade
       
 
        Nobu
       
 
        川音리오
       
 
        Maciek Palmowski
       
 
        Nestor Vera
       
 
        Daniel Roe
       
 
        Yue Yang
       
 
        Jeronimas
       
 
        Alessandro Carrano
       
 
        Clément Ollivier
       
 
        Alexander Lichter
       
 
        N3-rd
       
 
        Adrien Zaganelli
       
 
        Mag
       
 
        Stefan Huber
       
 
        Olga Bulat
       
 
        Paiva
       
 
        Florian Reuschel
       
 
        Savas Vedova
       
 
        Steven
       
 
        Vinícius Alves
       
 
        Kareem Dabbeet
       
 
        Valentín Costa
       
 
        Ryan Skinner
       
 
        Alex Hirzel
       
 
        Ajeet Chaulagain
       
 
        René Eschke
       
 
        Nico Devs
       
 
        Muhammad
       
 
        Naoki Hamada
       
 
        Tom
       
 
        Yann Aufray
       
 
        Anthony Chu
       
 
        Nuzhat Minhaz
       
 
        Lucas Portet
       
 
        Richard Schloss
       
 
        Bobby
       
 
        bpy
       
 
        Antony Konstantinidis
       
 
        Hibariya
       
 
        Jose Seabra
       
 
        Eze
       
 
        Florian Lefebvre
       
 
        Lucas Recoaro
       
 
        Julien SEIXAS