I've formatted this issue as a feature pitch / RFC with the format from luau-lang/rfcs/TEMPLATE.md

Darklua build result cache

Summary

> In short, I think Darklua needs a feature to include behavior to store the contents of files in some inexpensive way, like a hashed version of lua/luau files. This means Darklua will be able to skip unchanged files being built that have already been processed.

Motivation

> Build times in Darklua can be a major deciding factor in its adoption and continued usage. Lowering the time it takes for Darklua to build a project will result in an extremely enhanced developer experience as less time will be wasted waiting Up to 2-3 seconds++ on large projects. This proposal should mean effectively static build times for projects of any size + cost of processing changed files. I think this change is vital for Darklua to remain a useful & productive tool in Lua/Luau workflows.

Design

Configuration

> darklua.json will have a parameter for a default memoize level; off/input/inputoutput (can use shorthand: o/i/io)

• Memoize Level off:
  darklua build will perform no caching/hashing/etc. Every time build is run it will process every file individually without comparison.
• Memoize Level input:
  darklua build will perform and store comparisons & hashes of files in the input-path. This means that files which have changed contents in the input-path will be re-processed. The output path will not be considered.
• Memoize Level inputoutput:
  darklua build will perform and store comparisons & hashes of files in the input-path and output-path, guaranteeing no changes have been made to the code in the output path.

CLI

> CLI command darklua build will now have a --cache <memoize-level> and/or --memoize (identical) parameter. This parameter could either override or serve as a replacement for the darklua.json parameter mentioned above.

> New CLI command darklua erasecache will be introduced. This will clear your local build cache and require all files be reprocessed/hashed.

Cache Clearing

> Whenever changes are made to Darklua version, configuration files, or an attached sourcemap, file structure, etc. some or all of the "build cache" may need to be cleared. This should be done automatically.

Drawbacks

Fortunately, as far as I am aware no backwards/forwards compatibility issues are present with this feature request.

> This proposal could present significant performance drawbacks when hashing large portions or the entirety of a project. It also could introduce bugs with hash collisions and the cache failing to be invalidated. This feature is inherently opt-in, and would serve as an optimization tool for larger projects. When done right, hash collisions should be astronomically rare if possible. If/when they did occur, it would be fixed next time the hash changes (which is quite frequent), or whenever the cache gets invalidated through other means.
> This proposal also increases configuration/CLI complexity, and could require more work in the future.

Alternatives

> Pursue other forms of optimization. Introduce build-time optimizations and other optimizations that make Darklua more ergonomic and fast.
> Do nothing, and leave Darklua as-is. Build times are inherently non-blocking. Implementing this proposal results in potential performance drawbacks and increased complexity. Not to mention time invested that could be spent on bugs and other enhancements.

Both of the above options result in severely degraded DX compared to this feature being implemented. I think it is worth the effort to develop this feature for increased productivity and DX.