refactor: lift indexHtmlFile up to component, add validation

[ZachJW34]

• Closes UNIFY-1251

User facing changelog

Lift indexHtmlFile up to component config and validate the property is only valid on the component config.

Additional details

The PR is broken up into two commits, the first contains the logic for lifting the property and adding validation and the second adds the missing component-index.html file to projects that were relying on the default (hopefully makes it easier to review). There is no longer a fallback template for @cypress/webpack-dev-server and @cypress/vite-dev-server since we are scaffolding this file to the users project at cypress/support/component-index.html which will be the default value of component.indexHtmlFile.

There is validation of the indexHtmlFile property to ensure that it is not added at the root level of the config or in the e2e config. All devServers have been updated to pull this value from the cypress config rather than passing the option explicitly.

I did not implement the getTemplate API outlined in the issue as that is an implementation detail that should be implemented after the Object API is merged, I will update the ticket and create another one to implement it. We already have this logic inside of WizardActions, it's just not ideal but we can move forward without it.

The removal of the template property from @cypress/webpack-dev-server is a breaking change but we already plan on making breaking changes to the dev-servers. These changes won't be released until 10.0 and there is an issue for ensuring 9.x users don't use the 10.0 supported version. This property was mostly an internal property and not documented.

How has the user experience changed?

User no longer needs to specify indexHtmlFile in their config as config.component.indexHtmlFile will have a default value of cypress/support/component-index.html which is scaffolded for them during project setup.

Before:

module.exports = {
  component: {
  	devServer,
	devServerConfig: {
	  indexHtmlFile: 'cypress/support/component-index.html',
	},
  },
} 

After:

module.exports = {
  component: {
  	devServer,
  },
}

PR Tasks

• Have tests been added/updated?
• [NA] Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
• [NA] Has a PR for user-facing changes been opened in cypress-documentation? Notion is up to date
• Have API changes been updated in the type definitions?
• [NA] Have new configuration options been added to the cypress.schema.json?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

17792 • 0 • 217 • 0 • 1

---

Run details

Project	cypress
Status	Passed
Commit	c8e737a
Started	Apr 1, 2022 2:09 PM
Ended	Apr 1, 2022 2:22 PM
Duration	12:49 💡
OS	Linux Debian - 10.10
Browser	Multiple

View run in Cypress Dashboard ➡️

---

Flakiness

	cypress/e2e/cypress/source_map_utils.cy.js		1
1	driver/src/cypress/source_map_utils > .extractSourceMap > is performant with multiple source map comments in file

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[tgriesser]

Is there a reason we want this on CoreConfigOptions rather than ComponentConfigOptions?

[ZachJW34]

My understanding is that, once the config is resolved, you should access the properties as root level properties since testingType specific options are merged to be top-level. So inside of startServer.ts for webpack, you should be able to do config.indexHtmlFile rather than config.component.indexHtmlFile (the config passed into the devServer doesn't even have a component object so you can't do config.component.indexHtmlFile).

The options in ComponentConfigOptions aren't typed at the root level, so if I wanted to define them there we would have to refactor those types.

[tgriesser]

I think for the devServer we're generally going to be accessing the properties off of the un-merged config anyway, because the merging happens in the parent process and we can't serialize/unserialize a user's webpackConfig over the wire (ran into that when refactoring the object API)

The options in ComponentConfigOptions aren't typed at the root level,

Might not be sure what you're referring to - I was just saying to add the type to this interface:

interface ComponentConfigOptions<ComponentDevServerOpts = any> extends Omit<CoreConfigOptions, 'baseUrl'> {
    devServer: DevServerFn<ComponentDevServerOpts>
    devServerConfig?: ComponentDevServerOpts
}

And then use it from that to pass into startServer directly

[lmiller1990]

@ZachJW34 nice - this all seems pretty straight forward, since getTemplateHtml isn't implemented, and we are just lifting the indexHtmlFile up

If we are going to do the getTemplateHtml changes separately, I think we should:

1. Update the Jira ticket to reflect the actual work done here (right now based on Jira, it looks like everything should be here, which it's not)
2. Create a new ticket with the remaining work to be done

What do you think?

Not sure what's going on with Percy, 💀

[ZachJW34]

@lmiller1990 I'll update the issue now, was just going to wait a bit to see how the PR shakes out.

Updated and created a new issue. Merged latest master and the crazy Percy diffs went away.