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

fix: Extend mock logger used in angular bootstrap #25500

Merged
merged 4 commits into from
Jan 19, 2023

Conversation

mike-plummer
Copy link
Contributor

User facing changelog

Fixes an issue where Angular Component Testing projects would fail to initialize if an unsupported browserslist entry was specified in the project configuration.

Additional details

We were building an incomplete logger instance for use by @angular/devkit util functions - if an unsupported browserslist entry was specified the utils would try to make a logging call that would fail. This PR makes a couple changes:

  1. Extend the logger to provide more of the expected contract. Full compliance felt like overkill (25+ fields, hence the as unknown as logger.Logger cast) but this should cover most use cases
  2. Make the logger proxy output to debug so that it's available when troubleshooting - output would previously be swallowed
  3. Minor performance tweak so an expected failure occurs faster in tests

Steps to test

  1. Create an Angular v15 project: npx @angular/cli new my-project
  2. Create a .browserslistrc file with the content IE 11
  3. Open project in CT using v12.3.0, observe failure: npx cypress open --component
  4. Checkout this branch, do a yarn build in npm/webpack-dev-server, and open the project,. Observe no failure

How has the user experience changed?

Project with unsupported browserslist config will now open

PR Tasks

  • Have tests been added/updated?
  • 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?
  • [na] Have API changes been updated in the type definitions?

* Add missing logger functions that caused failure
* Proxy mock logger to debug so output isn't swallowed when troubleshooting
* Minor test performance improvement
@cypress
Copy link

cypress bot commented Jan 18, 2023



Test summary

26570 0 1279 0Flakiness 44


Run details

Project cypress
Status Passed
Commit 3c62db1
Started Jan 19, 2023 6:49 PM
Ended Jan 19, 2023 7:09 PM
Duration 19:31 💡
OS Linux Debian -
Browser Multiple

View run in Cypress Dashboard ➡️


Flakiness

commands/net_stubbing.cy.ts Flakiness
1 network stubbing > intercepting request > can delay and throttle a StaticResponse
2 ... > with `times` > only uses each handler N times
3 ... > stops waiting when an xhr request is canceled
4 network stubbing > intercepting request > can delay and throttle a StaticResponse
e2e/origin/cookie_behavior.cy.ts Flakiness
1 ... > same site / cross origin > XMLHttpRequest > sets cookie on same-site request if withCredentials is true, and attaches to same-site request if withCredentials is true
This comment includes only the first 5 flaky tests. See all 44 flaky tests in the Cypress Dashboard.

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

Copy link
Contributor

@astone123 astone123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice 👍🏻 good thinking proxying the logs to debug

@lmiller1990 lmiller1990 self-requested a review January 18, 2023 22:15
it('should live-reload on src changes', () => {
cy.visitApp()
cy.contains('app.component.cy.ts').click()
cy.waitForSpecToFinish({ passCount: 1 }, 60000)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not your change but woah,60000, does the spec really take that long to execute? 🐢

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The angular tests especially (and other frameworks to a lesser extent) take forever to bundle & launch webpack on Windows, so I think this was added to work around that.

@@ -203,14 +205,23 @@ export async function getAngularJson (projectRoot: string): Promise<AngularJson>
return JSON.parse(angularJson)
}

function buildLogger (name: string = ''): logging.Logger {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems this is only called once (below) and name is never passed, is that required, or can we remove the argument entirely?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's actually called in two places, one of which is within itself so it's easy to miss. We call it once with no name for the root logger, and the createChild signature accepts a name for child loggers

function buildLogger (name: string = ''): logging.Logger {
const debugLogger = debugLib(`${debugPrefix}${name ? `:${name}` : ''}`)

return {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cannot find any docs in Angular about the logger, nice job figuring this out.

Another option if we want to cover all bases might be using a Proxy and pointing everything that's not one of the properties you defined here as a no-op. Then if someone does something exotic like logger.subscribe() it wouldn't error (it also wouldn't do what they are expecting, though).

Will let you make the final call, just throwing another suggestion out there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took another look based on your suggestion and I ended up finding a better alternative - just build an actual Logger instance (which is really just a tracker for LogEntry items) and build a subscription that forwards everything to the debug logger. No idea why we weren't just building a Logger instance to begin with, but now we're fully compliant with the contract and get inspectability from the debug logger

@mike-plummer mike-plummer merged commit fdd402f into develop Jan 19, 2023
@mike-plummer mike-plummer deleted the mikep/25312-angular-logger branch January 19, 2023 22:01
@cypress-bot
Copy link
Contributor

cypress-bot bot commented Jan 24, 2023

Released in 12.4.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v12.4.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Jan 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"logger.warn is not a function" when webpack-dev-server calls build-angular/webpack-browser-config
4 participants