Port flatten task to v3 #6068

antico5 · 2024-12-19T15:32:35Z

This PR introduces an implementation for the flatten task. Both the implementation and the tests were ported and adapted from v2.

Details to point out:

The usage of the tsort package was replaced by toposort, which has 30x weekly download count and specially, it's typed.
On v2, there were multiple subtasks associated with flatten. The most important being (shortened): FLATTEN, GET_FLATTENED_SOURCE, GET_FLATTENED_SOURCE_AND_METADATA. I wasn't sure there was a need to define more than one task, so I went with this approach. Maybe I could move the printing (contract and warnings) to a separate one, in case just the flattened file and metadata need to be consumed by an external plugin.
For testing I used several fixture projects, which was the approach taken in v2. I noticed the engineering guidelines suggest to avoid this unless necessary, but I'd find it dificult to test this without using them. If we wanted that, we'd have to think about a mock filesystem/resolver.
For asserting stdio I hooked the console.log and console.warn implementations on the test cases. I tried to find an injection approach but it wasn't clear to me how, since tasks don't allow function arguments.
On v2 tests, flattened contracts were compiled. I didn't include that part on v3 tests, since I'm not sure it's in scope. As I understand it, the flatten task doesn't guarantee the the output is valid, compilable solidity code.

Closes #5647

vercel · 2024-12-19T15:32:40Z

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

Name	Status	Preview	Comments	Updated (UTC)
hardhat	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 19, 2024 3:32pm

changeset-bot · 2024-12-19T15:32:40Z

⚠️ No Changeset found

Latest commit: eca4985

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

github-actions · 2024-12-19T15:34:09Z

hardhat

Total size of the bundle: 229M
Total number of dependencies (including transitive): 62

List of dependencies (sorted by size)

224M	total
30M	@ignored/edr-optimism-linux-x64-musl
30M	@ignored/edr-optimism-linux-x64-gnu
27M	@ignored/edr-optimism-linux-arm64-musl
27M	@ignored/edr-optimism-linux-arm64-gnu
22M	@ignored/edr-optimism-win32-x64-msvc
21M	@ignored/edr-optimism-darwin-x64
20M	esbuild
20M	@ignored/edr-optimism-darwin-arm64
8.9M	solc
2.8M	@sentry/tracing
2.4M	micro-eth-signer
1.9M	@noble/curves
1.7M	undici
1.2M	@sentry/types
1.2M	@noble/hashes
932K	@sentry/node
920K	@sentry/utils
856K	zod
816K	@ignored/hardhat-vnext-utils
616K	micro-packed
576K	tsx
548K	@sentry/core
504K	fast-equals
492K	@scure/bip39
460K	@ignored/edr
384K	@ignored/edr-optimism
368K	ethereum-cryptography
344K	@sentry/hub
320K	enquirer
320K	@ignored/hardhat-vnext-errors
284K	semver
192K	ws
188K	commander
168K	@scure/base
136K	adm-zip
128K	get-tsconfig
96K	@scure/bip32
92K	chalk
88K	tslib
88K	@sentry/minimal
84K	js-sha3
76K	agent-base
72K	@nomicfoundation/solidity-analyzer
68K	debug
64K	lru_map
64K	https-proxy-agent
60K	@ignored/hardhat-vnext-zod-utils
56K	rfdc
56K	follow-redirects
48K	memorystream
48K	command-exists
48K	ansi-colors
44K	tmp
40K	toposort
40K	resolve-pkg-maps
36K	p-map
32K	cookie
24K	strip-ansi
24K	env-paths
24K	ansi-regex
20K	os-tmpdir
20K	ms

alcuadrado · 2025-01-12T19:52:53Z

v-next/hardhat/package.json

@@ -68,6 +68,7 @@
    "@types/debug": "^4.1.4",
    "@types/node": "^20.14.9",
    "@types/semver": "^7.5.8",
+    "@types/toposort": "^2.0.7",


We have an implementation of topological sort, which we should reuse

alcuadrado · 2025-01-12T20:34:01Z

v-next/hardhat/test/internal/builtin-plugins/flatten/task-action.ts

+  beforeEach(() => {
+    // Replace console.log and console.warn so we can assert on their output
+    consoleLogBuffer.length = 0;
+    consoleWarnBuffer.length = 0;
+
+    console.log = (...args: unknown[]) => {
+      consoleLogBuffer.push(args.join(" "));
+    };
+    console.warn = (...args: unknown[]) => {
+      consoleWarnBuffer.push(args.join(" "));
+    };
+  });
+
+  afterEach(() => {
+    console.log = originalConsoleLog;
+    console.warn = originalConsoleWarn;
+  });


Instead of doing this, the task action can accept these params

print = console.log, warn = console.warn

which are not exposed to the CLI, nor hooked into it in any way.

Then, to test it, we just need to call the task action directly.

alcuadrado · 2025-01-12T20:35:20Z

The usage of the tsort package was replaced by toposort, which has 30x weekly download count and specially, it's typed.

Also added a comment about this, but we already have an implementation of top sort.

On v2, there were multiple subtasks associated with flatten. The most important being (shortened): FLATTEN, GET_FLATTENED_SOURCE, GET_FLATTENED_SOURCE_AND_METADATA. I wasn't sure there was a need to define more than one task, so I went with this approach. Maybe I could move the printing (contract and warnings) to a separate one, in case just the flattened file and metadata need to be consumed by an external plugin.

Single task is the way to go. If we need to make something extensible, we can add hooks.

For testing I used several fixture projects, which was the approach taken in v2. I noticed the engineering guidelines suggest to avoid this unless necessary, but I'd find it dificult to test this without using them. If we wanted that, we'd have to think about a mock filesystem/resolver.

I guess it's fine for this case.

For asserting stdio I hooked the console.log and console.warn implementations on the test cases. I tried to find an injection approach but it wasn't clear to me how, since tasks don't allow function arguments.

See the comments.

On v2 tests, flattened contracts were compiled. I didn't include that part on v3 tests, since I'm not sure it's in scope. As I understand it, the flatten task doesn't guarantee the the output is valid, compilable solidity code.

I think this is ok.

Port flatten task to v3

eca4985

antico5 requested a review from alcuadrado December 19, 2024 15:32

github-actions bot added the status:triaging label Dec 19, 2024

github-actions bot assigned kanej Dec 19, 2024

schaable added status:ready This issue is ready to be worked on v-next A Hardhat v3 development task and removed status:triaging labels Dec 30, 2024

alcuadrado reviewed Jan 12, 2025

View reviewed changes

alcuadrado requested a review from galargh January 12, 2025 19:54

alcuadrado reviewed Jan 12, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Port flatten task to v3 #6068

Port flatten task to v3 #6068

antico5 commented Dec 19, 2024

vercel bot commented Dec 19, 2024

changeset-bot bot commented Dec 19, 2024

github-actions bot commented Dec 19, 2024

alcuadrado Jan 12, 2025

alcuadrado Jan 12, 2025

alcuadrado commented Jan 12, 2025

Port flatten task to v3 #6068

Are you sure you want to change the base?

Port flatten task to v3 #6068

Conversation

antico5 commented Dec 19, 2024

vercel bot commented Dec 19, 2024

changeset-bot bot commented Dec 19, 2024

⚠️ No Changeset found

github-actions bot commented Dec 19, 2024

hardhat

alcuadrado Jan 12, 2025

Choose a reason for hiding this comment

alcuadrado Jan 12, 2025

Choose a reason for hiding this comment

alcuadrado commented Jan 12, 2025