chore: make create function on server.ts obsolete

[sainthkh]

• Related with chore: revive type checker #18172

User facing changelog

N/A

Additional details

• Why was this change necessary? => When defining types, I had to define dummy Server type to avoid type failures. This PR removes it.
• What is affected by this change? => N/A
• Any implementation details to explain? => I moved code inside create() to Server class.

How has the user experience changed?

N/A

Notes.

I also thought about removing create() classes in some other files, but it is not an easy convert because they gets state, cy, Cypress as their argument to generate functions.

Maybe, I need to find a workaround for them.

PR Tasks

• Have tests been added/updated?

[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.

[BlueWinds]

The refactor itself looks good, only comments relate to the code under refactor.

[BlueWinds]

This is a weird conditional, ending up as (xhr.responseType === '' || xhr.responseType === 'text') && xhr.responseType === '' - meaning responseTypeIsTextOrEmptyString is unnecessary here. And since this is the only place in the code it's used, could probably be removed entirely.

I know you're just moving around existing code here, but seems worth cleaning up a bit while moving around.

[sainthkh]

I agree that it's really weird. But it seems that it is written in this way because of XMLHttpRequest's behavior: responseType is only accessible when its value is '' or 'text.

We should understand it like x && x.val when x is undefined.

Without this check, the test below will fail.

cypress/packages/driver/cypress/integration/commands/xhr_spec.js

Lines 2603 to 2630 in 349b06e

	// https://github.com/cypress-io/cypress/issues/3008
	it('aborts xhrs even when responseType not \'\' or \'text\'', () => {
	let log = null
	cy.on('log:changed', (attrs, l) => {
	if (['xhr', 'request'].includes(attrs.name)) {
	if (!log) {
	log = l
	}
	}
	})
	cy
	.window()
	.then((win) => {
	const xhr = new win.XMLHttpRequest()
	xhr.responseType = 'arraybuffer'
	xhr.open('GET', '/timeout?ms=1000')
	xhr.send()
	xhr.abort()
	cy.wrap(null).should(() => {
	expect(log.get('state')).to.eq('failed')
	expect(xhr.aborted).to.be.true
	})
	})
	})

[emilyrohrbough]

Could we define these types to match the types defined in the CLI?

[sainthkh]

These 2 are different. cy.server() is an old API that was used before cy.intercept() was created.

And this Server is Cypress.Server. It was also used internally for cy.server().

Only the public interface for Cypress.Server is defaults(). It seems that we have nothing to do for the types.

[emilyrohrbough]

Gottchya. Makes sense! Thanks for the info.

[emilyrohrbough]

This comment is a bit odd when reading through the code. Adding something like to cancel any pending xhrs would add more context.

[sainthkh]

Done.

[emilyrohrbough]

This can probably be removed

[sainthkh]

I tracked down the history and found out that these comments were introduced in 47410d5. It seems that it was a mistake.