Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: move tablegen to store and worldgen to world, update javascript build/export setup #640

Merged
merged 31 commits into from
Apr 20, 2023

Conversation

dk1a
Copy link
Member

@dk1a dk1a commented Apr 18, 2023

No description provided.

@vercel
Copy link

vercel bot commented Apr 18, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
mud ✅ Ready (Inspect) Visit Preview 💬 Add feedback Apr 20, 2023 6:48pm

"type": "module",
"exports": {
"./codegen": "./dist/codegen/index.js",
"./foundry": "./dist/foundry/index.js"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👏 this is nice, so we can import just what we need

I wonder if we should have some policy around deps for this package, to keep it slim/focused

],
"scripts": {
"build": "vite build",
"release": "npm publish --access=public",
Copy link
Member

@holic holic Apr 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed this sprinkled everywhere - is this needed? (No action needed here, I can clean this up separately if so, just curious)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you mean the release script? It's used by release:manual in the root package.json, which is useful if a lerna release fails midway (after increasing all versions etc) to just push the current state to npm

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in that case (assuming all release scripts are the same in each package), we can just recursively exec this same command but from the root package

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good! unrelated to this PR though, would leave that for a follow up

@@ -1,25 +1,25 @@
import { AbiTypeToSchemaType, getStaticByteLength, SchemaType, SchemaTypeToAbiType } from "@latticexyz/schema-type";
import { StoreConfig, parseStaticArray } from "@latticexyz/config";
import { RelativeImportDatum, RenderTableType } from "./types.js";
import { RelativeImportDatum, RenderType } from "./types.js";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed in some areas we're able to remove the .js and others not, is this intentional?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should be able to remove it everywhere now!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in 77487c0

@@ -9,9 +9,10 @@
},
"license": "MIT",
"type": "module",
"main": "dist/index.js",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does the removal of main in these packages mean we can import plainly as TS? or does importing end up using the JS build?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in vscode it's gonna resolve types immediately (via the types key), but during build it's gonna resolve to dist/index.js (via the exports key). This means to run tests etc we need to build first (which should be less of a pain once nx is added)

@@ -21,16 +22,15 @@
"@latticexyz/schema-type": "^1.42.0",
"chalk": "^5.2.0",
"esbuild": "^0.17.15",
"ethers": "^6.3.0",
"ethers": "^5.7.2",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oof, that would have been bad

"dist": "rimraf abi && mkdir abi && cp -rf out/*.sol/*.json abi/ && pnpm rimraf abi/*.metadata.json",
"build": "pnpm run build:js && pnpm run build:tightcoder && pnpm run build:codegen && pnpm run build:abi && pnpm run build:typechain",
"build:abi": "forge build --out abi --skip test script",
"build:codegen": "node ./dist/tablegen.js",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we use tsx and the source here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in 77487c0

formats: ["es"],
},
outDir: "dist",
minify: false,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not minify? there are some perks even on importing in node

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no reason, this was just a vite config i copied from another package, can probably enable minify

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will leave enabling this everywhere to a followup (in case this breaks something)

holic
holic previously approved these changes Apr 20, 2023
Copy link
Member

@holic holic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great! thanks everyone for slogging through this mess to get this over the finish line!

we should probably standardize how we organize packages with both solidity exports and ts/js exports

this PR now adds a ts dir to packages that previously only had solidity in src, which is different from e.g. schema-type that uses src/typescript and src/solidity

edit: added an issue to follow up here: #652

@holic
Copy link
Member

holic commented Apr 20, 2023

see https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c for CJS vs ESM

Copy link
Member Author

@dk1a dk1a left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

haha now I'm getting a failed build locally
Screenshot 2023-04-20 181336

Comment on lines +12 to +15
"exports": {
"./codegen": "./dist/codegen/index.js",
"./foundry": "./dist/foundry/index.js"
},
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this, I was thinking of multiple packages (hence common-codegen), but there's little to no benefit to splitting them I suppose

Copy link
Member

@holic holic Apr 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

only benefit I can see is if we need to introduce heavy deps, splitting out one of the "subpackages" into its own proper package may make sense, but we can address that when it comes up

Comment on lines +105 to +124
/**
* Executes the given command, returns the stdout, and logs the command to the console.
* Throws an error if the command fails.
* @param command The command to execute
* @param args The arguments to pass to the command
* @returns The stdout of the command
*/
async function execLog(command: string, args: string[], options?: Options<string>): Promise<string> {
const commandString = `${command} ${args.join(" ")}`;
try {
console.log(chalk.gray(`running "${commandString}"`));
const { stdout } = await execa(command, args, { stdout: "pipe", stderr: "pipe", ...options });
return stdout;
// eslint-disable-next-line @typescript-eslint/no-explicit-any
} catch (error: any) {
let errorMessage = error?.stderr || error?.message || "";
errorMessage += chalk.red(`\nError running "${commandString}"`);
throw new Error(errorMessage);
}
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will probably want to move this after utils refactoring is done to another common package

@@ -1,8 +1,8 @@
import { parseStoreConfig } from "@latticexyz/config";
import { tsgen } from "@latticexyz/cli/dist/render-ts";
import { tsgen } from "@latticexyz/cli";
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw I was thinking of moving this to recs, just didn't wanna overcomplicate this PR

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good!

const config = await loadStoreConfig();
const srcDir = await getSrcDirectory();

tablegen(config, path.join(srcDir, config.codegenDirectory));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs await

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch

const config = await loadStoreConfig();
const srcDir = await getSrcDirectory();

tablegen(config, path.join(srcDir, config.codegenDirectory));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also missing await?

@dk1a
Copy link
Member Author

dk1a commented Apr 20, 2023

also formatAndWriteSolidity in store/ts/render-solidity/tablegen.ts seems to be missing await, but that's not even related to this PR. I guess I forgot it but things still work cause those functions are quick

@@ -0,0 +1 @@
declare module "prettier-plugin-solidity";
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this shouldn't be needed in store and world, doing this in just common should be sufficient, as the other packages don't even directly install this plugin (at least locally for me it seems to work)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i had to add this yesterday to solve an error related to it, but can try to see if it also works without it now after shifting other things around 👀

"build": "pnpm codegen && rimraf out && forge build && pnpm dist && pnpm types && tsup",
"codegen": "tsx ./scripts/codegen.ts && prettier --write '**/*.sol'",
"dist": "rimraf abi && mkdir abi && cp -rf out/*.sol/*.json abi/ && pnpm rimraf abi/*.metadata.json",
"build": "pnpm run build:js && pnpm run build:tightcoder && pnpm run build:codegen && pnpm run build:abi && pnpm run build:typechain",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

putting build:js first is a bit different than my (ordered) list and expectations here: #633

this might be okay (just the dependencies for this package'sbuild:js step will be different), but wondering if it's okay that we don't run this step after other things (codegen, typechain)

if we have to run it twice, we might want to separate it into two different scripts/names so we can better build the nx pipelines around it

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right this wasn't part of my original commit, but as I was wrangling CI I tried building scripts, which had to happen before codegen, and so build:js became first
So unless we move "build:codegen": "node ./dist/tablegen.js", to tsx (I think that had some issues?) it still has to go before codegen

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think vite uses codegen's or typechain's results in any way, so it should be fine to just run the whole build:js 1st

Copy link
Member

@holic holic Apr 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a step like this going before is totally fine, we're just going to either need to

  • be careful about defining dependencies between different steps (build:js happens first here but last in other packages)
  • separate the "build JS for internal use" and "build JS for external use" steps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants