Feat/init script

[liamb13]

Sorry for the mess @Jamiewarb.

A couple of areas of concern in here. Struggled to get it running smoothly. But the idea was to capture the results of sanity init. Avoiding much manual work with updating variables.

    // Run sanity init
    console.log('\n📦 Running Sanity initialization...');
    console.log('Please follow the prompts to set up your Sanity project...');

    // Run Sanity init with full interactivity but capture stdout
    const sanityInit = spawn('npx', ['sanity', 'init', '--bare'], {
      stdio: ['inherit', 'pipe', 'inherit'],
      cwd: rootDir,
      env: {
        ...process.env,
        FORCE_COLOR: '1',
        CI: 'false',
        TERM: process.env.TERM || 'xterm-256color',
      },
    });

    let output = '';
    sanityInit.stdout.on('data', (data) => {
      const text = data.toString();
      output = text;

      // Remove the first line of the project selection prompt
      if (text.includes('Create new project') && !text.includes('(Use arrow keys)')) {
        let cleanedText = text.replace(
          '\x1B[32m?\x1B[39m \x1B[1mCreate a new project or select an existing one\x1B[22m\x1B[0m \x1B[0m\n',
          '',
        );
        console.log(cleanedText);
        return;
      }

      if (text.includes('Select dataset to use') && !text.includes('(Use arrow keys)')) {
        let cleanedText = text.replace(
          '\x1B[32m?\x1B[39m \x1B[1mSelect dataset to use\x1B[22m\x1B[0m \x1B[0m\n',
          '',
        );
        console.log(cleanedText);
        return;
      }

      console.log(text);
    });

I also haven't tested the sample data import, but set it up. I've also added a github workflow (untested) that should catch any changes to the sample data in any prs. My thoughts here is this would be an automated action, and should only ever happen from the templates project.

[Jamiewarb]

Cheers Liam. Looks like a great start.

One comment I'd have is if we can break up the script into self-documenting function calls that encapsulate the functionality within. Then we can quickly read down the list of function calls to see what's happening in the script without working it out from the implementation.

[liamb13]

Cheers Liam. Looks like a great start.

One comment I'd have is if we can break up the script into self-documenting function calls that encapsulate the functionality within. Then we can quickly read down the list of function calls to see what's happening in the script without working it out from the implementation.

Thanks @Jamiewarb. Code should be a bit easier to read now.

The CLI parsing is also improved.