Create a first class API to explicitly define the type of response

[whydoievenneedthis]

Current behavior

I am making a JSONP call. The point is that I want to include some trusted thrid-party javascript to my site, and have it evald.

Assuming I would want to get jquery dynamically pulled in on production, while in the test I want to do some magic instead, I would create a jquery.js file in the fixtures directory and do:

cy.intercept(
  { method: 'GET', url: 'http://jquery.com/jquery.min.js' },
  { fixture: 'jquery.js' }
)

This however results in the well-known error:

An error was thrown while processing a network event: 'jquery.js' is not a valid JavaScript object.
SyntaxError: Unexpected token ';'

If I simply rename the file to jquery.txt, it works fine, but then I don't have any of the IDE tools to edit a js file.

Desired behavior

When a JS file is being used as a fixture in an intercept call, cypress does not even attempt to interpret it, and just passes down the content. This is because Cypress automatically assumes js files are js that is evaluated and returns a js object. It would be nice to have a first class mechanism to specify the type expected for files in general. If this were the case, you could treat a JS file appropriately in this scenario.

Test code to reproduce

Failing test:

https://github.com/whydoievenneedthis/cypress-test-jsonp-js-fixture/blob/master/cypress/e2e/spec.cy.js

Cypress Version

11.0.0

Node version

18.10.0

Operating System

windows 10

Debug Logs

No response

Other

This is not a duplicate of #1271

[ryanthemanuel]

Hi @whydoievenneedthis, thank you for logging this issue. By default cypress treats the contents of a js file as a JSON object. I believe to accomplish what you will want to accomplish, you can jquery.js,null as the fixture. The null will tell it to just use the contents as is without trying to automatically convert it to an object (See the note at the bottom of this section https://docs.cypress.io/api/commands/fixture#Encoding). Does that work for you?

[whydoievenneedthis]

Hi @ryanthemanuel, this is what I was looking for, thanks. Now that I know what I am looking for, I was able to find the info in the documentation as well, but I still think it would make sense to have the ,null behaviour the default for the interception fixtures.

[ryanthemanuel]

@whydoievenneedthis I updated this to be a feature request. I think the experience we've seen thus far is for JS files to return JS objects; however, I could see a use case for specifying the type for a given fixture in a more first class fashion. Routing this to the e2e team for prioritization.

[wylieconlon]

I also was able to use the fixture: 'myFile.js,null' workaround, but the docs on this were actually wrong- they say that ,null will always treat the data as Buffer:

You can specify null as the encoding in order to read the file as a Cypress.Buffer instance instead.

From https://docs.cypress.io/api/commands/fixture#Encoding

Is that a separate request to update the docs on this use case?