···11+# LunAST
22+33+LunAST is an experimental in-development [AST](https://en.wikipedia.org/wiki/Abstract_syntax_tree)-based remapper and patcher for Webpack modules.
44+55+## Introduction
66+77+Modern Webpack patching functions off of matching existing minified code (using a string or regular expression) and then replacing it. While this is an easy to use and powerful way of patching Webpack modules, there are many downsides:
88+99+- Even the smallest change can break patches, which can require lots of maintenance, especially on large Discord bundler changes.
1010+- Fetching exports from a Webpack module will sometimes result in minified export names. These exports must be manually remapped to human readable names by a library extension.
1111+- Making complicated patches is extremely difficult and means your patch has more points of failure.
1212+1313+To solve this, LunAST generates [the ESTree format](https://github.com/estree/estree) with a handful of libraries ([meriyah](https://github.com/meriyah/meriyah), [estree-toolkit](https://github.com/sarsamurmu/estree-toolkit), [astring](https://github.com/davidbonnet/astring)) on each Webpack module. This makes large-scale manipulation and mapping feasible, by allowing you to write code to detect what modules you want to find.
1414+1515+## Usage
1616+1717+### Embedding into your own code
1818+1919+LunAST is not ready to be used in other projects just yet. In the future, LunAST will be a standalone library.
2020+2121+### Registering a processor
2222+2323+LunAST functions off of "processors". Processors have a unique ID, an optional filter (string or regex) on what to parse, and a process function which receives the AST.
2424+2525+The process function returns a boolean, which when true will unregister the processor. Once you have found what you're looking for, you can return true to skip parsing any other subsequent module, speeding up load times.
2626+2727+LunAST includes some core processors, and extensions can register their own processors (citation needed).
2828+2929+```ts
3030+register({
3131+ name: "UniqueIDForTheProcessorSystem",
3232+ find: "some string or regex to search for", // optional
3333+ priority: 0, // optional
3434+ process({ id, ast, lunast }) {
3535+ // do some stuff with the ast
3636+ return false; // return true to unregister
3737+ }
3838+});
3939+```
4040+4141+### Mapping with LunAST
4242+4343+LunAST can use proxies to remap minified export names to more human readable ones. Let's say that you determined the module ID and export name of a component you want in a module.
4444+4545+First, you must define the type. A type contains a unique name and a list of fields. These fields contain the minified name and the human-readable name that can be used in code.
4646+4747+Then, register the module, with the ID passed to you in the process function. Specify its type so the remapper knows what fields to remap. It is suggested to name the module and type with the same name.
4848+4949+```ts
5050+process({ id, ast, lunast }) {
5151+ let exportName: string | null = null;
5252+5353+ // some code to discover the export name...
5454+5555+ if (exportName != null) {
5656+ lunast.addType({
5757+ name: "SomeModule",
5858+ fields: [
5959+ {
6060+ name: "SomeComponent",
6161+ unmapped: exportName
6262+ }
6363+ ]
6464+ });
6565+ lunast.addModule({
6666+ name: "SomeModule",
6767+ id,
6868+ type: "SomeModule"
6969+ });
7070+ return true;
7171+ }
7272+7373+ return false;
7474+}
7575+```
7676+7777+Then, you need to specify the type of the module in `types.ts`. Using the `import` statement in Webpack modules is not supported yet. Hopefully this step is automated in the future.
7878+7979+After all this, fetch the remapped module and its remapped field:
8080+8181+```ts
8282+moonlight.lunast.remap("SomeModule").SomeComponent
8383+```
8484+8585+### Patching with LunAST
8686+8787+LunAST also enables you to modify the AST and then rebuild a module string from the modified AST. It is suggested you read the [estree-toolkit](https://estree-toolkit.netlify.app/welcome) documentation.
8888+8989+You can use the `magicAST` function to turn some JavaScript code into another AST node, and then merge/replace the original AST.
9090+9191+**After you modify the AST, call the markDirty function.** LunAST will not know to replace the module otherwise.
9292+9393+```ts
9494+process({ ast, markDirty }) {
9595+ const node = /* do something with the AST */;
9696+ if (node != null) {
9797+ const replacement = magicAST("return 1 + 1");
9898+ node.replaceWith(replacement);
9999+ markDirty();
100100+ return true;
101101+ }
102102+103103+ return false;
104104+}
105105+```
106106+107107+## FAQ
108108+109109+### How do you fetch the scripts to parse?
110110+111111+Fetching the content of the `<script>` tags is impossible, and making a `fetch` request would result in different headers to what the client would normally send. We use `Function.prototype.toString()` and wrap the function in parentheses to ensure the anonymous function is valid JavaScript.
112112+113113+### Isn't this slow?
114114+115115+Not really. LunAST runs in roughly ~10ms on [my](https://github.com/NotNite) machine, with filtering for what modules to parse. Parsing every module takes only a second. There are future plans to cache and parallelize the process, so that load times are only slow once.
116116+117117+You can measure how long LunAST took to process with the `moonlight.lunast.elapsed` variable
118118+119119+### Does this mean patches are dead?
120120+121121+No. Patches will continue to serve their purpose and be supported in moonlight, no matter what. LunAST should also work with patches, but patches may conflict or not match.
122122+123123+[astring](https://github.com/davidbonnet/astring) may need to be forked in the future to output code without whitespace, in the event patches fail to match on AST-patched code.
124124+125125+### This API surface seems kind of bad
126126+127127+This is still in heavy development and all suggestions on how to improve it are welcome. :3
128128+129129+### Can I help?
130130+131131+Discussion takes place in the [moonlight Discord server](https://discord.gg/FdZBTFCP6F) and its `#lunast-devel` channel.
+1-1
packages/lunast/TODO.md
···33- [ ] Experiment more! We need to know what's bad with this
44- [ ] Write utility functions for imports, exports, etc.
55 - [ ] Imports
66- - [ ] Exports
66+ - [x] Exports
77 - [ ] Constant bindings for an object
88- [ ] Map Z/ZP to default
99- [x] Steal Webpack require and use it in our LunAST instance