Resource manifest fields and safe defaults

Use manifest snippets to start a resource; use this page to review what that manifest actually loads and distributes. fxmanifest.lua declares resource metadata in its own Lua runtime. Defining a variable there does not create a shared variable in your client or server scripts.

Separate executable scripts from downloaded files

These meanings follow the official manifest reference . Treat a broadly matched files entry as a publication decision. Never include credentials, database exports, private logs or server configuration in a catch-all download glob. A file being named server.lua does not protect it if another declaration explicitly distributes it.

Audit a concrete file layout

Suppose a resource contains:

doc_notice/
  fxmanifest.lua
  config.public.lua
  client.lua
  server.lua
  html/
    index.html
    app.js
    style.css

An explicit manifest for those files is:

fx_version 'cerulean'
game 'gta5'
 
shared_script 'config.public.lua'
client_script 'client.lua'
server_script 'server.lua'
 
ui_page 'html/index.html'
files {
    'html/index.html',
    'html/app.js',
    'html/style.css'
}

This is a file-layout example, not a downloadable application: create the referenced files before starting it. Keep config.public.lua limited to values clients are allowed to read. Put secrets in server-controlled configuration and review every export or event that could send them back to a client.

To review an existing resource, enumerate each manifest pattern against the actual directory, then inspect the resulting file list. Remove stale build outputs rather than solving missing-file warnings with files '**/*'. Finally open the NUI on a test client and check its network requests: an HTML file loading successfully does not prove that its JavaScript, styles and fonts were included. Use NUI diagnostics for callback and focus problems.

Declare dependencies without pretending they configure code

A dependency names a resource that must load first; dependencies accepts several. Runtime constraints can require a minimum server, game build, OneSync, policy or server native. For example, /onesync is a capability constraint, not the name of a resource. Only declare requirements your implementation genuinely has.

-- Add to a resource that actually consumes these capabilities.
dependencies {
    'spawnmanager',
    '/onesync'
}

Test with each prerequisite intentionally unavailable on a disposable server and check that startup fails as expected. A successful dependency check does not configure the provider, migrate your database or guarantee API compatibility. Similarly, provide 'another-resource' declares a replacement; it does not implement the replaced resource’s exports for you.

Do not add every dependency from a tutorial to every resource. A dependency-free client math example does not need a framework, database library or OneSync simply because another guide does.

Maps, data files and loading screens

For mapped content, this_is_a_map marks a map resource and data_file selects the appropriate game data loader. A filename extension is not enough to choose a loader type. Use the asset-authoring lab for a complete manifest matched to actual YTYP/YMAP output rather than mixing declarations from unrelated vehicle and map recipes.

loadscreen selects a loading-screen page; manual shutdown is a separate lifecycle choice. Follow loading-screen messages and cleanup, including its matching HTML and client behavior. An ordinary ui_page is not automatically a loading screen.

escrow_ignore selects editable files for Asset Escrow; it is not an authorization rule or a replacement for reviewing client downloads. See Asset Escrow before changing an asset author’s intended packaging.

Review runtime flags before copying them

The current reference marks lua54 as deprecated because Lua 5.4 is already used. Do not add it as a missing prerequisite when debugging a new resource. For JavaScript, node_version '22' selects a server runtime; it does not change NUI’s browser or the client runtime.

use_experimental_fxv2_oal changes native argument handling and remains experimental. In that mode, vector arguments are not automatically unpacked. Compare explicit position.x, position.y, position.z arguments against the actual native signature before changing flags. Do not market enabling OAL as a universally safe performance fix.

Avoid resurrecting resource_manifest_version, before_level_meta or after_level_meta from old snippets as default modern declarations. Review the current replacement for the particular resource. For C# task scheduling flags, use the C# async guide; changing a manifest flag is not a substitute for understanding the scheduler.

Diagnose one failure at a time

Restart the resource after a manifest edit and record the client track, FXServer artifact and first relevant error. Verify downloads from a test client as well as server logs. These are review and acceptance steps; this guide does not claim that the illustrative file layout was run as a complete FiveM application.

For exact field syntax and uncommon metadata such as FxDK convar_category, consult the pinned upstream manifest . This page is a practical audit guide, not a duplicate of every manifest field or historical FX version.