testdata: add testdata package

[gabrocheleau]

No description provided.

[jochem-brouwer]

I had not thought about actually making this a package, but I think this makes sense. So this would be the "devDependency" package where we can put test files + helpers in?

The alternative to just make this a folder and on importing test data relative to the test (so `import { hardfork4844Data } from '../../testdata/src' for instance) would be a bit ugly 🤔 (Thinking out loud a bit, I was thinking of the testdata as "just a folder" and not package)

[gabrocheleau]

I had not thought about actually making this a package, but I think this makes sense. So this would be the "devDependency" package where we can put test files + helpers in?

The alternative to just make this a folder and on importing test data relative to the test (so `import { hardfork4844Data } from '../../testdata/src' for instance) would be a bit ugly 🤔 (Thinking out loud a bit, I was thinking of the testdata as "just a folder" and not package)

Yeah I'm not actually sure. It is actually typescript code it felt out of place to put it at the root level under ./testdata (alongside config) but it's certainly an option. I'm definitely not sold on the current approach (conceptually it's not really a "package" in my view. I'll experiment and see what works best.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.

Project coverage is 79.60%. Comparing base (d6d3858) to head (a98e895).
Report is 1 commits behind head on master.

Additional details and impacted files

Flag	Coverage Δ
block	83.29% <ø> (ø)
blockchain	89.33% <ø> (ø)
client	68.10% <ø> (ø)
common	97.54% <ø> (-0.95%)	⬇️
devp2p	86.73% <ø> (ø)
evm	72.98% <ø> (ø)
genesis	99.98% <ø> (ø)
mpt	89.71% <ø> (-0.06%)	⬇️
rlp	91.43% <ø> (ø)
statemanager	69.16% <ø> (ø)
tx	90.58% <ø> (ø)
util	81.96% <ø> (ø)
vm	57.20% <0.00%> (ø)
wallet	88.55% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[holgerd77]

Not doing a full review, just some notes, generally looks really great, also think at second look that the @ethereumjs/testdata package naming is ok/good (so, also for clarification: so now we are not going with the "folder import + symlinking" import for some (implicit ?) reasons?).

I think it's important that we establish a somewhat solid test data folder structure from the beginning, so that things remain somewhat sorted and re-discoverable, this also helps to accidentally re-add the same test data.

From having a quick look I would suggest the following first-round folders:

• chains/geth (for files like goerliGethGenesis.ts)
• chains/custom (for our custom chain definitions like goerliChainConfig)
• blocks (e.g. preLondonTestData1.ts)

Then people are also encouraged to directly add to this structure, e.g. if there is tx testdata or something else which is structurally different.

[gabrocheleau]

Not doing a full review, just some notes, generally looks really great, also think at second look that the @ethereumjs/testdata package naming is ok/good (so, also for clarification: so now we are not going with the "folder import + symlinking" import for some (implicit ?) reasons?).

I think it's important that we establish a somewhat solid test data folder structure from the beginning, so that things remain somewhat sorted and re-discoverable, this also helps to accidentally re-add the same test data.

From having a quick look I would suggest the following first-round folders:

• chains/geth (for files like goerliGethGenesis.ts)
• chains/custom (for our custom chain definitions like goerliChainConfig)
• blocks (e.g. preLondonTestData1.ts)

Then people are also encouraged to directly add to this structure, e.g. if there is tx testdata or something else which is structurally different.

Thanks for commenting!

Concerning the package naming, this approach actually did not work, notably because symlinking/alias is just equivalent to a relative imports, and we can't do relative imports in our packages. See some complaints when TS when I attempted that approach:

More conversation happened about this in the tech-internal channel.

Sure, I like the recommendation about folders. Wdyt if we do without the nested folders for chains to keep a flatter structure? E.g.:

• gethGenesis
• chainConfigs
• blocks
• (eventally?) transactions

[acolytec3]

Do we actually need a build step here?

[gabrocheleau]

My underestanding is that it's best to do it to enable tests to be run with nodejs (otherwise users would need to use tsx/ts-node)

[acolytec3]

I deleted the dist folder from testdata and ran all the tests locally and they pass just fine. This is what I expected since our code is intended to use typescript sources and vitest uses a transpiler internally to handle typescript code. Since this package is for local testing only and not intended to be published, I'd advocate to skip the build step entirely so as to not add anything else to the CI (even though this admittedly won't add much)

[gabrocheleau]

Ah! Nice, thanks for actually trying this out. Will remove the build step and add the necessary --if-present flag so that the root postinstall doesn't fail on that package.

[gabrocheleau]

Done! Feel free to re-approve! :)

[acolytec3]

This is awesome. Great start on this!

[holgerd77]

Yes, agree, super great start! 🙂❤️