nuxt-bun-compile 0.1.25 → 0.1.27
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +12 -173
- package/README.ptBR.md +12 -173
- package/dist/module.json +1 -1
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
[](https://badge.socket.dev/npm/package/nuxt-bun-compile/0.1.0)
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
<img src="/images/logo-transparent--nuxt-bun-compile.png" alt="Logo Nuxt Bun Compile" width="50%">
|
|
6
6
|
|
|
7
7
|
> 🚀 Nuxt module that automatically configures Nitro for `bun build --compile`, generating a **standalone executable binary** from your Nuxt app — zero runtime dependencies needed.
|
|
8
8
|
|
|
@@ -24,9 +24,9 @@ bun nuxt add nuxt-bun-compile
|
|
|
24
24
|
bun run -b build
|
|
25
25
|
```
|
|
26
26
|
|
|
27
|
-
[Why is `-b` required?](
|
|
27
|
+
[Why is `-b` required?](/docs/ARCHITECTURE.md#why-is--b-required)
|
|
28
28
|
|
|
29
|
-
[If you encounter memory issues during build](
|
|
29
|
+
[If you encounter memory issues during build](/docs/NOTES.md#why-node_options--max-old-space-size8192)
|
|
30
30
|
|
|
31
31
|
**Step 3: Run your binary**
|
|
32
32
|
|
|
@@ -41,160 +41,15 @@ That's it. One binary. No `node_modules`. No runtime. Just your app.
|
|
|
41
41
|
|
|
42
42
|
---
|
|
43
43
|
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
| Setting | Value | Why |
|
|
55
|
-
|---|---|---|
|
|
56
|
-
| `preset` | `"bun"` | Target the Bun runtime |
|
|
57
|
-
| `noExternals` | `true` | Bundle everything into the output |
|
|
58
|
-
| `inlineDynamicImports` | `true` | Flatten dynamic imports for single-file output |
|
|
59
|
-
| `serveStatic` | `"inline"` | Embed static assets in the binary |
|
|
60
|
-
| `esbuild.options.target` | `"esnext"` | Use latest JS features for maximum performance |
|
|
61
|
-
|
|
62
|
-
---
|
|
63
|
-
|
|
64
|
-
## ⚙️ Options
|
|
65
|
-
|
|
66
|
-
| Option | Type | Default | Description |
|
|
67
|
-
|---|---|---|---|
|
|
68
|
-
| `enabled` | `boolean` | `true` | Enable/disable the module |
|
|
69
|
-
| `outfile` | `string` | `"nuxtbin"` | Output binary filename |
|
|
70
|
-
| `bunPath` | `string` | `undefined` | Path to the bun executable. Can be a directory (e.g., `/opt/bun/`) or a direct path to the binary (e.g., `/opt/bun/bun`). If it's a directory, '/bun' will be appended. Defaults to 'bun' from the system's PATH. |
|
|
71
|
-
| `target` | `'bun-linux-x64' \| 'bun-linux-x64-musl' \| 'bun-linux-arm64' \| 'bun-linux-arm64-musl'` | `auto-detected` | Target platform for binary compilation. Auto-detects your system architecture (x64/arm64) and libc type (glibc/musl). Override only if auto-detection fails or you need a specific target. |
|
|
72
|
-
| `extraExternals` | `(string \| RegExp)[]` | `[]` | Additional packages to mark as external |
|
|
73
|
-
| `autoCompile` | `boolean` | `true` | Run `bun build --compile` automatically after build |
|
|
74
|
-
|
|
75
|
-
---
|
|
76
|
-
|
|
77
|
-
## 📦 Default External Packages
|
|
78
|
-
|
|
79
|
-
These packages are known to break with `noExternals: true` and are excluded by default:
|
|
80
|
-
|
|
81
|
-
| Package | Pattern |
|
|
82
|
-
|---|---|
|
|
83
|
-
| sharp | `sharp` |
|
|
84
|
-
| @img | `@img/*` |
|
|
85
|
-
| css-tree | `css-tree`, `css-tree/*` |
|
|
86
|
-
| csso | `csso`, `csso/*` |
|
|
87
|
-
| svgo | `svgo` |
|
|
88
|
-
| mdn-data | `mdn-data`, `mdn-data/*` |
|
|
89
|
-
|
|
90
|
-
Need to add more? Use `extraExternals`:
|
|
91
|
-
|
|
92
|
-
```ts
|
|
93
|
-
bunCompile: {
|
|
94
|
-
extraExternals: ["problematic-package", /^@scope\//],
|
|
95
|
-
}
|
|
96
|
-
```
|
|
97
|
-
|
|
98
|
-
> **⚠️ Important:** Libraries listed in `extraExternals` (as well as the default externals) are **not embedded in the binary**. For the `nuxtbin` binary to run correctly, these dependencies must be available in a `node_modules` folder alongside the generated binary.
|
|
99
|
-
|
|
100
|
-
---
|
|
101
|
-
|
|
102
|
-
## ⚠️ Native Dependencies in Alpine Linux
|
|
103
|
-
|
|
104
|
-
When compiling with `--target=bun-linux-x64-musl` or `--target=bun-linux-arm64-musl` (Alpine), the resulting binary still dynamically links to `libstdc++` and `libgcc` at runtime. This is documented Bun behavior:
|
|
105
|
-
|
|
106
|
-
- [oven-sh/bun#23910](https://github.com/oven-sh/bun/issues/23910)
|
|
107
|
-
- [oven-sh/bun#918](https://github.com/oven-sh/bun/issues/918)
|
|
108
|
-
|
|
109
|
-
### Solution: Install Required Libraries in Docker
|
|
110
|
-
|
|
111
|
-
If running the binary in an Alpine Linux container, install the required libraries:
|
|
112
|
-
|
|
113
|
-
```dockerfile
|
|
114
|
-
FROM alpine:latest
|
|
115
|
-
|
|
116
|
-
RUN apk add --no-cache libstdc++ libgcc
|
|
117
|
-
|
|
118
|
-
COPY nuxtbin /app/
|
|
119
|
-
WORKDIR /app
|
|
120
|
-
|
|
121
|
-
CMD ["./nuxtbin"]
|
|
122
|
-
```
|
|
123
|
-
|
|
124
|
-
This ensures all runtime dependencies are available in the container.
|
|
125
|
-
|
|
126
|
-
---
|
|
127
|
-
|
|
128
|
-
## 🏗️ Architecture
|
|
129
|
-
|
|
130
|
-
The module uses a **hook-based architecture**:
|
|
131
|
-
|
|
132
|
-
- **`nitro:config`** — Adjusts Nitro settings (preset, externals, bundling)
|
|
133
|
-
- **`nitro:compiled`** — Triggers `bun build --compile` after Nitro finishes building the server
|
|
134
|
-
|
|
135
|
-
### How It Works
|
|
136
|
-
|
|
137
|
-
```
|
|
138
|
-
bun run -b build
|
|
139
|
-
│
|
|
140
|
-
├─ nitro:config hook ──▶ Configure preset, bundling, externals
|
|
141
|
-
│
|
|
142
|
-
├─ Nuxt/Nitro build pipeline runs normally
|
|
143
|
-
│
|
|
144
|
-
└─ nitro compiled hook ──▶ bun build .output/server/index.mjs --compile --outfile <name>
|
|
145
|
-
│
|
|
146
|
-
└──▶ 🎉 Standalone binary ready!
|
|
147
|
-
```
|
|
148
|
-
|
|
149
|
-
### Why is `-b` required?
|
|
150
|
-
|
|
151
|
-
When you run `bun run build` (without `-b`), Bun acts as a **task runner** and may delegate script execution to Node.js. In that scenario, `globalThis.Bun` and `process.versions.bun` **do not exist**, and the module cannot detect the Bun runtime:
|
|
152
|
-
|
|
153
|
-
```ts
|
|
154
|
-
const isBun = typeof globalThis.Bun !== "undefined"
|
|
155
|
-
|| process.versions.bun !== undefined;
|
|
156
|
-
```
|
|
157
|
-
[src/module.ts:L70-L76](https://github.com/jprando/nuxt-bun-compile/blob/main/src/module.ts#L70-L76)
|
|
158
|
-
|
|
159
|
-
The **`-b`** (or `--bun`) flag forces Bun to be the runtime that executes the script. With it, the variables above become available and the `bun build --compile` step runs correctly.
|
|
160
|
-
|
|
161
|
-
---
|
|
162
|
-
|
|
163
|
-
## 🛠️ Tech Stack
|
|
164
|
-
|
|
165
|
-
| | Technology | Details |
|
|
166
|
-
|---|---|---|
|
|
167
|
-
| 🔤 | **TypeScript** | ESNext target, strict mode, bundler resolution |
|
|
168
|
-
| 🐰 | **Bun** | Runtime 1.3.9+, package manager |
|
|
169
|
-
| 💚 | **Nuxt** | 4.x |
|
|
170
|
-
| 📐 | **dprint** | Code formatter (TS, JSON, MD, TOML, YAML, and more) |
|
|
171
|
-
| 📦 | **ESM** | Pure ES modules (`"type": "module"`) |
|
|
172
|
-
|
|
173
|
-
---
|
|
174
|
-
|
|
175
|
-
## 🧑💻 Development
|
|
176
|
-
|
|
177
|
-
### Testing Locally in a Nuxt App
|
|
178
|
-
|
|
179
|
-
```bash
|
|
180
|
-
# 1. Clone this repo for local development
|
|
181
|
-
git clone https://github.com/jprando/nuxt-bun-compile.git
|
|
182
|
-
|
|
183
|
-
# 2. Link the module
|
|
184
|
-
cd nuxt-bun-compile && bun install && bun prepack && bun link
|
|
185
|
-
|
|
186
|
-
# 3. Use it in your Nuxt app
|
|
187
|
-
cd your-nuxt-app && bun link nuxt-bun-compile
|
|
188
|
-
|
|
189
|
-
# 4. Add to nuxt.config.ts modules array
|
|
190
|
-
bun nuxt add nuxt-bun-compile
|
|
191
|
-
|
|
192
|
-
# 5. Build
|
|
193
|
-
NODE_OPTIONS="--max-old-space-size=8192" bun run -b build
|
|
194
|
-
|
|
195
|
-
# 6. Run the binary
|
|
196
|
-
./nuxtbin
|
|
197
|
-
```
|
|
44
|
+
- [🎯 What It Does](/docs/WHAT-IT-DOES.md)
|
|
45
|
+
- [⚙️ Options](/docs/OPTIONS.md)
|
|
46
|
+
- [📦 Default External Packages](/docs/DEFAULT-EXTERNAL-PACKAGES.md)
|
|
47
|
+
- [⚠️ Native Dependencies in Alpine Linux](/docs/NATIVE-DEPENDENCIES-IN-ALPINE-LINUX.md)
|
|
48
|
+
- [🏗️ Architecture](/docs/ARCHITECTURE.md)
|
|
49
|
+
- [📚 Usage Examples](/docs/USAGE-EXAMPLES.md)
|
|
50
|
+
- [🧑💻 Development](/docs/DEVELOPMENT.md)
|
|
51
|
+
- [🛠️ Tech Stack](/docs/TECH-STACK.md)
|
|
52
|
+
- [📝 Notes](/docs/NOTES.md)
|
|
198
53
|
|
|
199
54
|
---
|
|
200
55
|
|
|
@@ -206,22 +61,6 @@ NODE_OPTIONS="--max-old-space-size=8192" bun run -b build
|
|
|
206
61
|
|
|
207
62
|
---
|
|
208
63
|
|
|
209
|
-
## 📝 Notes
|
|
210
|
-
|
|
211
|
-
### Why `NODE_OPTIONS="--max-old-space-size=8192"`?
|
|
212
|
-
|
|
213
|
-
The Nuxt build process with `noExternals: true` and `inlineDynamicImports: true` causes Rollup/esbuild to bundle **all** dependencies into a single output. In projects with many dependencies, this can consume more memory than the default V8 heap limit (approximately 1.5–2 GB), resulting in the error:
|
|
214
|
-
|
|
215
|
-
```
|
|
216
|
-
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
|
|
217
|
-
```
|
|
218
|
-
|
|
219
|
-
The `NODE_OPTIONS="--max-old-space-size=8192"` variable increases the V8 heap memory limit to 8 GB, providing enough headroom for the bundling process to complete. The value of `8192` (MB) is a safe reference for most projects — adjust as needed for larger projects or machines with less RAM.
|
|
220
|
-
|
|
221
|
-
> **Note:** This variable affects the Node.js/V8 process that runs the Nuxt build, not the final binary generated by `bun build --compile`.
|
|
222
|
-
|
|
223
|
-
---
|
|
224
|
-
|
|
225
64
|
## 📄 License
|
|
226
65
|
|
|
227
66
|
MIT
|
package/README.ptBR.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
[](https://badge.socket.dev/npm/package/nuxt-bun-compile/0.1.0)
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
<img src="/images/logo-transparent--nuxt-bun-compile.png" alt="Logo Nuxt Bun Compile" width="50%">
|
|
6
6
|
|
|
7
7
|
> 🚀 Módulo Nuxt que configura automaticamente o Nitro para `bun build --compile`, gerando um **binário executável standalone** a partir da sua aplicação Nuxt — sem dependências de runtime.
|
|
8
8
|
|
|
@@ -24,9 +24,9 @@ bun nuxt add nuxt-bun-compile
|
|
|
24
24
|
bun run -b build
|
|
25
25
|
```
|
|
26
26
|
|
|
27
|
-
[Por que é necessário o parâmetro `-b`?](
|
|
27
|
+
[Por que é necessário o parâmetro `-b`?](/docs/ARCHITECTURE.ptBR.md#por-que--b-é-obrigatório)
|
|
28
28
|
|
|
29
|
-
[Se você enfrentar problemas de memória durante a compilação](
|
|
29
|
+
[Se você enfrentar problemas de memória durante a compilação](/docs/NOTES.ptBR.md#por-que-node_options--max-old-space-size8192)
|
|
30
30
|
|
|
31
31
|
**Passo 3: Executar seu binário**
|
|
32
32
|
|
|
@@ -41,160 +41,15 @@ Só um binário. Sem `node_modules`. Sem runtime. Apenas sua aplicação.
|
|
|
41
41
|
|
|
42
42
|
---
|
|
43
43
|
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
| Configuração | Valor | Motivo |
|
|
55
|
-
|---|---|---|
|
|
56
|
-
| `preset` | `"bun"` | Usar o runtime Bun como alvo |
|
|
57
|
-
| `noExternals` | `true` | Empacotar tudo no output |
|
|
58
|
-
| `inlineDynamicImports` | `true` | Achatar imports dinâmicos para output em arquivo único |
|
|
59
|
-
| `serveStatic` | `"inline"` | Embutir assets estáticos no binário |
|
|
60
|
-
| `esbuild.options.target` | `"esnext"` | Usar as features JS mais recentes para máximo desempenho |
|
|
61
|
-
|
|
62
|
-
---
|
|
63
|
-
|
|
64
|
-
## ⚙️ Opções
|
|
65
|
-
|
|
66
|
-
| Opção | Tipo | Padrão | Descrição |
|
|
67
|
-
|---|---|---|---|
|
|
68
|
-
| `enabled` | `boolean` | `true` | Habilitar/desabilitar o módulo |
|
|
69
|
-
| `outfile` | `string` | `"nuxtbin"` | Nome do arquivo binário de saída |
|
|
70
|
-
| `bunPath` | `string` | `undefined` | Caminho para o executável do bun. Pode ser um diretório (ex: `/opt/bun/`) ou o caminho direto para o binário (ex: `/opt/bun/bun`). Se for um diretório, '/bun' será anexado. O padrão é 'bun' do PATH do sistema. |
|
|
71
|
-
| `target` | `'bun-linux-x64' \| 'bun-linux-x64-musl' \| 'bun-linux-arm64' \| 'bun-linux-arm64-musl'` | `auto-detectado` | Plataforma alvo para compilação do binário. Auto-detecta sua arquitetura (x64/arm64) e tipo de libc (glibc/musl). Sobrescreva apenas se a auto-detecção falhar ou você precisar de um target específico. |
|
|
72
|
-
| `extraExternals` | `(string \| RegExp)[]` | `[]` | Pacotes adicionais para marcar como external |
|
|
73
|
-
| `autoCompile` | `boolean` | `true` | Executar `bun build --compile` automaticamente após o build |
|
|
74
|
-
|
|
75
|
-
---
|
|
76
|
-
|
|
77
|
-
## 📦 Pacotes External Padrão
|
|
78
|
-
|
|
79
|
-
Estes pacotes são conhecidos por quebrar com `noExternals: true` e são excluídos por padrão:
|
|
80
|
-
|
|
81
|
-
| Pacote | Pattern |
|
|
82
|
-
|---|---|
|
|
83
|
-
| sharp | `sharp` |
|
|
84
|
-
| @img | `@img/*` |
|
|
85
|
-
| css-tree | `css-tree`, `css-tree/*` |
|
|
86
|
-
| csso | `csso`, `csso/*` |
|
|
87
|
-
| svgo | `svgo` |
|
|
88
|
-
| mdn-data | `mdn-data`, `mdn-data/*` |
|
|
89
|
-
|
|
90
|
-
Precisa adicionar mais? Use `extraExternals`:
|
|
91
|
-
|
|
92
|
-
```ts
|
|
93
|
-
bunCompile: {
|
|
94
|
-
extraExternals: ["problematic-package", /^@scope\//],
|
|
95
|
-
}
|
|
96
|
-
```
|
|
97
|
-
|
|
98
|
-
> **⚠️ Importante:** As bibliotecas listadas em `extraExternals` (assim como as externals padrão) **não são embutidas no binário**. Para que o binário `nuxtbin` execute corretamente, essas dependências precisam estar disponíveis em uma pasta `node_modules` ao lado do binário gerado.
|
|
99
|
-
|
|
100
|
-
---
|
|
101
|
-
|
|
102
|
-
## ⚠️ Dependências Nativas no Alpine Linux
|
|
103
|
-
|
|
104
|
-
Ao compilar com `--target=bun-linux-x64-musl` ou `--target=bun-linux-arm64-musl` (Alpine), o binário resultante ainda faz link dinâmico com `libstdc++` e `libgcc` em tempo de execução. Este é um comportamento documentado do Bun:
|
|
105
|
-
|
|
106
|
-
- [oven-sh/bun#23910](https://github.com/oven-sh/bun/issues/23910)
|
|
107
|
-
- [oven-sh/bun#918](https://github.com/oven-sh/bun/issues/918)
|
|
108
|
-
|
|
109
|
-
### Solução: Instalar Bibliotecas Necessárias no Docker
|
|
110
|
-
|
|
111
|
-
Se rodar o binário em um container Alpine Linux, instale as bibliotecas necessárias:
|
|
112
|
-
|
|
113
|
-
```dockerfile
|
|
114
|
-
FROM alpine:latest
|
|
115
|
-
|
|
116
|
-
RUN apk add --no-cache libstdc++ libgcc
|
|
117
|
-
|
|
118
|
-
COPY nuxtbin /app/
|
|
119
|
-
WORKDIR /app
|
|
120
|
-
|
|
121
|
-
CMD ["./nuxtbin"]
|
|
122
|
-
```
|
|
123
|
-
|
|
124
|
-
Isso garante que todas as dependências de runtime estejam disponíveis no container.
|
|
125
|
-
|
|
126
|
-
---
|
|
127
|
-
|
|
128
|
-
## 🏗️ Arquitetura
|
|
129
|
-
|
|
130
|
-
O módulo usa uma **arquitetura baseada em hooks**:
|
|
131
|
-
|
|
132
|
-
- **`nitro:config`** — Ajusta configurações do Nitro (preset, externals, bundling)
|
|
133
|
-
- **`nitro:compiled`** — Aciona `bun build --compile` após o Nitro terminar o build do servidor
|
|
134
|
-
|
|
135
|
-
### Como Funciona
|
|
136
|
-
|
|
137
|
-
```
|
|
138
|
-
bun run -b build
|
|
139
|
-
│
|
|
140
|
-
├─ hook nitro:config ──▶ Configura preset, bundling, externals
|
|
141
|
-
│
|
|
142
|
-
├─ Pipeline de build Nuxt/Nitro executa normalmente
|
|
143
|
-
│
|
|
144
|
-
└─ hook nitro compiled ──▶ bun build .output/server/index.mjs --compile --outfile <nome>
|
|
145
|
-
│
|
|
146
|
-
└──▶ 🎉 Binário standalone pronto!
|
|
147
|
-
```
|
|
148
|
-
|
|
149
|
-
### Por que `-b` é obrigatório?
|
|
150
|
-
|
|
151
|
-
Quando você executa `bun run build` (sem `-b`), o Bun age como um **gerenciador de tarefas** e pode delegar a execução do script ao Node.js. Nesse cenário, as variáveis `globalThis.Bun` e `process.versions.bun` **não existem**, e o módulo não consegue detectar o runtime Bun:
|
|
152
|
-
|
|
153
|
-
```ts
|
|
154
|
-
const isBun = typeof globalThis.Bun !== "undefined"
|
|
155
|
-
|| process.versions.bun !== undefined;
|
|
156
|
-
```
|
|
157
|
-
[src/module.ts:L70-L76](https://github.com/jprando/nuxt-bun-compile/blob/main/src/module.ts#L70-L76)
|
|
158
|
-
|
|
159
|
-
O parâmetro **`-b`** (ou `--bun`) força o Bun a ser o runtime que executa o script. Com ele, as variáveis acima ficam disponíveis e a etapa de `bun build --compile` é executada corretamente.
|
|
160
|
-
|
|
161
|
-
---
|
|
162
|
-
|
|
163
|
-
## 🛠️ Tech Stack
|
|
164
|
-
|
|
165
|
-
| | Tecnologia | Detalhes |
|
|
166
|
-
|---|---|---|
|
|
167
|
-
| 🔤 | **TypeScript** | Target ESNext, strict mode, bundler resolution |
|
|
168
|
-
| 🐰 | **Bun** | Runtime 1.3.9+, gerenciador de pacotes |
|
|
169
|
-
| 💚 | **Nuxt** | 4.x |
|
|
170
|
-
| 📐 | **dprint** | Formatador de código (TS, JSON, MD, TOML, YAML e mais) |
|
|
171
|
-
| 📦 | **ESM** | ES modules puro (`"type": "module"`) |
|
|
172
|
-
|
|
173
|
-
---
|
|
174
|
-
|
|
175
|
-
## 🧑💻 Desenvolvimento
|
|
176
|
-
|
|
177
|
-
### Testando Localmente em uma Aplicação Nuxt
|
|
178
|
-
|
|
179
|
-
```bash
|
|
180
|
-
# 1. Clone este repositório para desenvolvimento local
|
|
181
|
-
git clone https://github.com/jprando/nuxt-bun-compile.git
|
|
182
|
-
|
|
183
|
-
# 2. Linke o módulo
|
|
184
|
-
cd nuxt-bun-compile && bun install && bun prepack && bun link
|
|
185
|
-
|
|
186
|
-
# 3. Use em sua aplicação Nuxt
|
|
187
|
-
cd sua-app-nuxt && bun link nuxt-bun-compile
|
|
188
|
-
|
|
189
|
-
# 4. Adicione ao array modules no nuxt.config.ts
|
|
190
|
-
bun nuxt add nuxt-bun-compile
|
|
191
|
-
|
|
192
|
-
# 5. Compile
|
|
193
|
-
NODE_OPTIONS="--max-old-space-size=8192" bun run -b build
|
|
194
|
-
|
|
195
|
-
# 6. Execute o binário
|
|
196
|
-
./nuxtbin
|
|
197
|
-
```
|
|
44
|
+
- [🎯 O que Faz](/docs/WHAT-IT-DOES.ptBR.md)
|
|
45
|
+
- [⚙️ Opções](/docs/OPTIONS.ptBR.md)
|
|
46
|
+
- [📦 Pacotes External Padrão](/docs/DEFAULT-EXTERNAL-PACKAGES.ptBR.md)
|
|
47
|
+
- [⚠️ Dependências Nativas no Alpine Linux](/docs/NATIVE-DEPENDENCIES-IN-ALPINE-LINUX.ptBR.md)
|
|
48
|
+
- [🏗️ Arquitetura](/docs/ARCHITECTURE.ptBR.md)
|
|
49
|
+
- [📚 Exemplos de Uso](/docs/USAGE-EXAMPLES.ptBR.md)
|
|
50
|
+
- [🧑💻 Desenvolvimento](/docs/DEVELOPMENT.ptBR.md)
|
|
51
|
+
- [🛠️ Tech Stack](/docs/TECH-STACK.ptBR.md)
|
|
52
|
+
- [📝 Notas](/docs/NOTES.ptBR.md)
|
|
198
53
|
|
|
199
54
|
---
|
|
200
55
|
|
|
@@ -206,22 +61,6 @@ NODE_OPTIONS="--max-old-space-size=8192" bun run -b build
|
|
|
206
61
|
|
|
207
62
|
---
|
|
208
63
|
|
|
209
|
-
## 📝 Notas
|
|
210
|
-
|
|
211
|
-
### Por que `NODE_OPTIONS="--max-old-space-size=8192"`?
|
|
212
|
-
|
|
213
|
-
O processo de build do Nuxt com `noExternals: true` e `inlineDynamicImports: true` faz com que o Rollup/esbuild tente empacotar **todas** as dependências em um único bundle. Em projetos com muitas dependências, isso pode consumir mais memória do que o limite padrão do V8 (aproximadamente 1.5–2 GB), causando o erro:
|
|
214
|
-
|
|
215
|
-
```
|
|
216
|
-
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
|
|
217
|
-
```
|
|
218
|
-
|
|
219
|
-
A variável `NODE_OPTIONS="--max-old-space-size=8192"` aumenta o limite de memória heap do V8 para 8 GB, dando margem suficiente para que o bundling termine sem estourar a memória. O valor de `8192` (MB) é uma referência segura para a maioria dos projetos — ajuste conforme necessário para projetos maiores ou máquinas com menos RAM.
|
|
220
|
-
|
|
221
|
-
> **Nota:** Essa variável afeta o processo do Node.js/V8 que roda o build do Nuxt, e não o binário final gerado pelo `bun build --compile`.
|
|
222
|
-
|
|
223
|
-
---
|
|
224
|
-
|
|
225
64
|
## 📄 Licença
|
|
226
65
|
|
|
227
66
|
MIT
|
package/dist/module.json
CHANGED
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "nuxt-bun-compile",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.27",
|
|
4
4
|
"description": "Nuxt module that automatically configures Nitro for `bun build --compile`, generating a standalone executable binary from your Nuxt app.",
|
|
5
5
|
"repository": "jprando/nuxt-bun-compile",
|
|
6
6
|
"license": "MIT",
|