-
Notifications
You must be signed in to change notification settings - Fork 200
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
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
819f5fa
to
ea11712
Compare
7d14757
to
1b5d789
Compare
1b5d789
to
db8544a
Compare
"type": "module", | ||
"exports": { | ||
"./codegen": "./dist/codegen/index.js", | ||
"./foundry": "./dist/foundry/index.js" |
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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"; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
There was a problem hiding this 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
see https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c for CJS vs ESM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"exports": { | ||
"./codegen": "./dist/codegen/index.js", | ||
"./foundry": "./dist/foundry/index.js" | ||
}, |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
/** | ||
* 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); | ||
} | ||
} |
There was a problem hiding this comment.
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"; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also missing await?
also |
This reverts commit 77487c0.
@@ -0,0 +1 @@ | |||
declare module "prettier-plugin-solidity"; |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
No description provided.