Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cypress CT + Angular can't resolve assets from stylesheets #29483

Open
leosvelperez opened this issue May 7, 2024 · 8 comments
Open

Cypress CT + Angular can't resolve assets from stylesheets #29483

leosvelperez opened this issue May 7, 2024 · 8 comments
Labels
CT Issue related to component testing npm: @cypress/angular @cypress/angular package issues

Comments

@leosvelperez
Copy link
Contributor

Current behavior

When running Cypress CT on an Angular project where assets are copied from a directory structure other than <project-root>/src/assets to /assets (probably when the number of path segments is different between source and destination), the assets can't be resolved from stylesheets. Serving the application works correctly.

// angular.json
{
  ...
  "projects": {
    "ng-cypress-ct-issue": {
      ...
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:application",
          "options": {
            ...
            "assets": [
              "src/favicon.ico",
              {
                "glob": "**/*",
                "input": "src/public/assets",
                "output": "/assets"
              }
            ],
          }
        },
        ...
      }
    }
  }
}
# src/app/app.component.scss
.logo {
  width: 200px;
  height: 200px;
  background-image: url("/assets/logo.svg");
}

When running Cypress CT (ng run <project>:ct), the image is not displayed and an error is printed in the terminal:

ERROR in ./src/app/app.component.scss?ngResource
Module Error (from ./node_modules/.pnpm/[email protected][email protected][email protected][email protected]/node_modules/postcss-loader/dist/cjs.js):
/Users/leosvel/code/playground/ng-cypress-ct-issue/src/app/app.component.scss:4:2: Can't resolve '../assets/logo.svg' in '/Users/leosvel/code/playground/ng-cypress-ct-issue/src/app'

Desired behavior

Running Cypress CT on an Angular project should work correctly and resolve assets regardless of their directory structure as long as their configuration is correct and they work when serving the application.

Test code to reproduce

Repo: https://github.com/leosvelperez/ng-cypress-ct-issue

Reproduction steps:

git clone https://github.com/leosvelperez/ng-cypress-ct-issue.git
cd ng-cypress-ct-issue
pnpm i
pnpm run ct # ng run ng-cypress-ct-issue:ct --no-watch

Cypress Version

13.8.1

Node version

v20.12.0

Operating System

macOS 14.4.1

Debug Logs

No response

Other

No response

@jennifer-shehane jennifer-shehane added CT Issue related to component testing npm: @cypress/angular @cypress/angular package issues labels May 7, 2024
@leosvelperez
Copy link
Contributor Author

Even when using a standard src/assets directory, there's an extra small issue with the <img> tag. If the provided path has a leading / the image is not resolved correctly, and there's a 404 error in the network tab. If there's no leading / it works correctly. That is the opposite of what it works for using url() from the stylesheet. In that case, the asset must have a leading /.

Below are the Cypress dev server logs for the requests in the application:

GET /assets/logo.svg 404 5.606 ms - -
GET /__cypress/src/assets/logo.svg 200 5.000 ms - -
GET /__cypress/src/logo.svg 200 7.885 ms - -
GET /__cypress/src/OpenSans-Regular.ttf 200 5.762 ms - -
  • The first corresponds to the <img> tag with a src of /assets/logo.svg
  • The second corresponds to the <img> tag with a src of assets/logo.svg
  • The third and fourth are the ones loaded from the stylesheet (both use a leading /, otherwise they throw)

This is not a major issue. I don't think it's blocking anyone. The <img> tag source can be set to paths without a leading / as a workaround. It's inconsistent with how the paths need to be set in the stylesheets, and it might be inconvenient if folks have to change their project's source code to accommodate Cypress CT, though.

Note that the Angular application is correctly served with either path.

I updated the shared repo to showcase this as well. The branch https://github.com/leosvelperez/ng-cypress-ct-issue/tree/standard-assets-dir has the standard src/assets directory where it can be seen the stylesheets resolving the assets correctly, but the <img> tag with the leading / (the same path used in the stylesheets) doesn't work.

@joewIST
Copy link

joewIST commented May 28, 2024

We are also facing this issue and it's causing our component tests to fail. Any help from Cypress team would be appreciated!

@konstantinschuette
Copy link

Would be great if someone could help here

@atomicrobokid
Copy link

Same issue here as well

Raised an issue NX side that has a repro in #27344 but looking at other reports on the NX page, seems to be a Cypress issue (which is how i found this thread)

@wmarques
Copy link

wmarques commented Sep 4, 2024

Same issue here, happened since we switched to the ESBuild builder.

By the way it seems that Cypress CT Angular always uses Webpack under the hood, wouldn't it be better to switch to ESBuild if the Angular app is configured to use ESBuild ?

I can help on that if I have some guidance

@konstantinschuette
Copy link

Could someone please take a look? We would like to start with component testing, but it's super distracting when both terminal and console are flooded with errors, because the assets couldn't be resolved.

@tomalaforge
Copy link

Any progress on this issue, or any workaround ?

@konstantinschuette
Copy link

Sadly not. It's still blocking us from using the component tests, as the viewport looks completely broken and the terminal is spammed with errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CT Issue related to component testing npm: @cypress/angular @cypress/angular package issues
Projects
None yet
Development

No branches or pull requests

7 participants