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

feat: on new-opened models, enable all projects #575

Closed
wants to merge 7 commits into from

Conversation

Skn0tt
Copy link
Member

@Skn0tt Skn0tt commented Dec 16, 2024

@Skn0tt Skn0tt self-assigned this Dec 16, 2024

Choose a reason for hiding this comment

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

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

src/testModel.ts:121

  • Ensure that there are tests verifying that all projects are enabled when no settings are found. The previous logic had a special case for the first project, which is now removed. Verify that this change doesn't break any existing functionality.
project.isEnabled = true;
model._loadModelIfNeeded(configSettings).then(() => {
this._didUpdate.fire();
if (userGesture)
this._saveSettings();
Copy link
Member Author

Choose a reason for hiding this comment

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

Before, we were saving settings immediately before reading them in this._configSettings. This breaks the "no settings yet" path in _loadModelIfNeeded, and broke tests intrack-config.spec.ts. By moving the save settings call after the _loadModel, we keep the "no settings yet" path working.

Copy link
Member

Choose a reason for hiding this comment

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

How is the following case handled:

  • I am like 90% of our users
  • I created a playwright project a year ago, I only have one config, 'chromium' was checked for me automatically
  • For the last year I was pressing "Run" button and I was getting all my tests run against Chromium
  • I don't expect this to change when I update extension.

Copy link
Member Author

@Skn0tt Skn0tt Dec 17, 2024

Choose a reason for hiding this comment

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

Well when I wrote this I tried to change it a way that existing users don't have any changes. Migrating settings is wicked though, so let me try writing a test to verify this.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh no :/ If the user never made a gesture that invokes _saveSettings, then their workspace settings are undefined, making them indistinguishable from users opening a new workspace. Not sure why, but I somehow assumed that we'd save settings immediately on opening. I'll have to rethink this.

@Skn0tt
Copy link
Member Author

Skn0tt commented Dec 17, 2024

After talking to Max and Dima about it, it looks like we currently don't have any markers to distinguish existing users from new users. If we want to prevent breaking changes to existing users' workflows, while also changing default settings, we'll need to add a marker first. I'll close this PR for now and work on shipping that marker first.

@Skn0tt Skn0tt closed this Dec 17, 2024
@Skn0tt
Copy link
Member Author

Skn0tt commented Dec 17, 2024

Here's a PR to add that marker: #577

After rolling that out, we'll wait for a couple of weeks for folks to update + activate that code in their Playwright workspace. Those workspaces will then be detectable as existing workspaces, so they don't get the new project defaults.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature]: Enable all projects by default in VS Code
2 participants