Scaffold config new template

[rin-st]

to test:

yarn cli -e rin-st/scaffold-config-test

note: resulting code doesn't have explaining comments inside the config like in se-2 or this create-eth template

Result:

import * as chains from "viem/chains";

export type ScaffoldConfig = {
  targetNetworks: readonly chains.Chain[];
  pollingInterval: number;
  alchemyApiKey: string;
  walletConnectProjectId: string;
  onlyLocalBurnerWallet: boolean;
};

export const DEFAULT_ALCHEMY_API_KEY = "oKxs-03sij-U_N0iOlrSsZFr29-IqbuF";

// Custom variables
const CUSTOM_API_KEY = process.env.CUSTOM_API_KEY;

const scaffoldConfig: ScaffoldConfig = {
  alchemyApiKey: process.env.NEXT_PUBLIC_ALCHEMY_API_KEY || DEFAULT_ALCHEMY_API_KEY,
  walletConnectProjectId: process.env.NEXT_PUBLIC_WALLET_CONNECT_PROJECT_ID || "3a8170812b534d0ff9d794f19a901d64",
  targetNetworks: [chains.hardhat, chains.base],
  pollingInterval: 12345,
  onlyLocalBurnerWallet: false,
};

export default scaffoldConfig;

extension: https://github.com/rin-st/scaffold-config-test

[technophile-04]

Thanks Rinat 🙏!! But I think the way we added new args doesn't provide full customizability also loosing those comments feels bad :(

So like we need this two main things:

1. Adding new properties to scaffold config object.
   • currently we can't do it because there is no way to extend types and even though we pass extra properties in configOverride it error out because of types constrain ScaffoldConfig
2. Not loosing the current comments.

So to tackle 1 & 2:

1. We have type baseConfig and merge that with extension type config to form final ScaffoldConfig type.
2. For comments, instead of having on them object let's move them inside the types?

Something like this:

scaffold.config.ts.template.mjs

import { withDefaults, stringify, deepMerge } from "../../../../templates/utils.js";

const defaultScaffoldConfig = {
  targetNetworks: ["$$chains.mainnet$$"],
  pollingInterval: 30000,
  alchemyApiKey: "$$process.env.NEXT_PUBLIC_ALCHEMY_API_KEY || DEFAULT_ALCHEMY_API_KEY$$",
  walletConnectProjectId: "$$process.env.NEXT_PUBLIC_WALLET_CONNECT_PROJECT_ID || '3a8170812b534d0ff9d794f19a901d64'$$",
  onlyLocalBurnerWallet: true,
};

const contents = ({ preConfigContent, configOverrides, configTypeName }) => {
  // add solidityFramework network
  const targetNetworks = configOverrides.map(override => override.targetNetworks).flat();
  const extensionConfigOverrides = configOverrides[configOverrides.length - 1] || {};
  if (targetNetworks?.length && Object.keys(extensionConfigOverrides).length > 0) {
    extensionConfigOverrides.targetNetworks = targetNetworks;
  }

  // Merge the default config with any overrides
  const finalConfig = deepMerge(defaultScaffoldConfig, extensionConfigOverrides);

  return  `import * as chains from "viem/chains";
${preConfigContent[0] || ''}

export type baseConfig = {
  // The networks on which your DApp is live
  targetNetworks: readonly chains.Chain[];
  
  // The interval at which your front-end polls the RPC servers for new data
  // it has no effect if you only target the local network (default is 4000)
  pollingInterval: number;
  
  // This is ours Alchemy's default API key.
  // You can get your own at https://dashboard.alchemyapi.io
  // It's recommended to store it in an env variable:
  // .env.local for local testing, and in the Vercel/system env config for live apps.
  alchemyApiKey: string;
  
  // This is ours WalletConnect's default project ID.
  // You can get your own at https://cloud.walletconnect.com
  // It's recommended to store it in an env variable:
  // .env.local for local testing, and in the Vercel/system env config for live apps.
  walletConnectProjectId: string;
  
  // Only show the Burner Wallet when running on hardhat network
  onlyLocalBurnerWallet: boolean;
};

export type ScaffoldConfig = baseConfig ${configTypeName[0] ? `& ${configTypeName[0]}` : ''};

export const DEFAULT_ALCHEMY_API_KEY = "oKxs-03sij-U_N0iOlrSsZFr29-IqbuF";

const scaffoldConfig: ScaffoldConfig = ${stringify(finalConfig)};

export default scaffoldConfig;`;
};

export default withDefaults(contents, {
  preConfigContent: "",
  configOverrides: {},
  configTypeName: "",
});

scaffold.config.ts.args.mjs

export const preConfigContent = `
// Custom variables
const CUSTOM_API_KEY = process.env.CUSTOM_API_KEY;

export type ExtraConfig = {
  // Random comment
  customApiKey: string | undefined;
}`;

export const configTypeName = "ExtraConfig";

export const configOverrides = {
  targetNetworks: ["$$chains.base$$"],
  pollingInterval: 12_345,
  onlyLocalBurnerWallet: false,
  customApiKey: "$$CUSTOM_API_KEY$$",
};

But maybe I am missing and there might be simpler approach and would love to know it!

Also lol we have discovered a case types as args, maybe in above example I passs them as string but not sure if ihave any other better approach?

[rin-st]

Great points @technophile-04 ! Updated PR

I didn't even think we need to care about adding new keys to scaffold config, maybe since it's relatively rare case. But you are 100% right we need to add it!

Regarding types I thought about this options:

• hardcode type name, something like AdditionalExtensionScaffoldConfigs so we don't need to pass it. But user could occasionally change it in predefined config and everything can break
• use typeof keyof configOverrides as additional type. But in this case that new type can have intersections with BaseConfig if something from default config is overridden

So for now I left it as you proposed (just change variable name to extraConfigTypeName)
Thanks!

[technophile-04]

Thanks @rin-st! Looks good! just fixed some issues in b899ec7. Also created an example scaffold-eth/create-eth-extensions#56 pointing to example-beta maybe we keep updating that branch when we update the .template.mjs and finally when we are ready we merge example-beta => example.

To test run:

yarn cli -e https://github.com/scaffold-eth/create-eth-extensions/tree/beta-scaffold-config

Also just cc @carletex on his views on #227 (review)

[technophile-04]

Ohh @rin-st just noticed a small bug, if you have multiple networks here https://github.com/scaffold-eth/create-eth-extensions/blob/3ac0c00a2ea966ab252a6cdcf7f60762611f5d13/extension/packages/nextjs/scaffold.config.ts.args.mjs#L16

Its does not spread both it just shows the first one

if you run :

yarn cli -e https://github.com/scaffold-eth/create-eth-extensions/tree/beta-scaffold-config

[rin-st]

Ohh @rin-st just noticed a small bug, if you have multiple networks here https://github.com/scaffold-eth/create-eth-extensions/blob/3ac0c00a2ea966ab252a6cdcf7f60762611f5d13/extension/packages/nextjs/scaffold.config.ts.args.mjs#L16
Its does not spread both it just shows the first one

Could you explain what you expect to get and what are you getting as a result. For me it seems its working as expected

For example if I have targetNetworks: ["$$customChain$$", "$$chains.baseSepolia$$"] in configOverrides and chose hardhat as solidityFramework, result is targetNetworks: [ chains.hardhat, customChain, chains.baseSepolia ],. Looks like everything is right

[technophile-04]

Could you explain what you expect to get and what are you getting as a result. For me it seems its working as expected

Ohh ohh my bad, lol I had lot of branches while testing and didn't push the multichain args commit to https://github.com/scaffold-eth/create-eth-extensions/tree/beta-scaffold-config but now it working great 🙌