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

chore: rework component onboarding in launchpad #25713

Merged
merged 40 commits into from
Feb 13, 2023

Conversation

lmiller1990
Copy link
Contributor

@lmiller1990 lmiller1990 commented Feb 6, 2023

Targeting a feature branch - feature/ct-public-api.

Brief: https://github.com/cypress-io/engineering-documentation/tree/main/tech-briefs/ct-public-api

Closes: #25681

This is only one part of the feature, the other part is to detect the custom implementations and add them into Launchpad is tracked here: #25680

This is just a refactor. There is no user facing change. The main goal was to rework the code so third parties can embed their own setup workflow in the Launchpad. I left some comments in the PR code showing where and how this is now possible.

@cypress
Copy link

cypress bot commented Feb 6, 2023

39 flaky tests on run #43987 ↗︎

0 26787 1271 0 Flakiness 39

Details:

correct label
Project: cypress Commit: 45bbd45a5e
Status: Passed Duration: 17:09 💡
Started: Feb 13, 2023 12:12 AM Ended: Feb 13, 2023 12:29 AM
Flakiness  e2e/origin/cookie_login.cy.ts • 1 flaky test • 5x-driver-electron

View Output Video

Test
cy.origin - cookie login > Max-Age > past max-age -> not logged in
Flakiness  e2e/origin/cookie_behavior.cy.ts • 4 flaky tests • 5x-driver-electron

View Output Video

Test
... > 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
... > same site / cross origin > fetch > sets same-site cookies if "include" credentials option is specified from request, but does not attach same-site cookies to request by default (same-origin)
... > 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
... > same site / cross origin > fetch > sets same-site cookies if "include" credentials option is specified from request, but does not attach same-site cookies to request by default (same-origin)
Flakiness  cypress/cypress.cy.js • 3 flaky tests • 5x-driver-electron

View Output Video

Test
... > correctly returns currentRetry
... > correctly returns currentRetry
... > correctly returns currentRetry
Flakiness  commands/net_stubbing.cy.ts • 1 flaky test • 5x-driver-firefox

View Output Video

Test
network stubbing > intercepting request > can delay and throttle a StaticResponse
Flakiness  e2e/origin/commands/assertions.cy.ts • 1 flaky test • 5x-driver-firefox

View Output Video

Test
cy.origin assertions > #consoleProps > .should() and .and()

The first 5 flaky specs are shown, see all 18 specs in Cypress Cloud.

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.

@lmiller1990 lmiller1990 changed the base branch from develop to feature/ct-public-api February 7, 2023 03:24
@@ -197,6 +198,8 @@ export function makeCoreData (modeOptions: Partial<AllModeOptions> = {}): CoreDa
chosenManualInstall: false,
detectedBundler: null,
detectedFramework: null,
// TODO: API to add third party frameworks to this list.
frameworks: CT_FRAMEWORKS.map((framework) => resolveComponentFrameworkDefinition(framework)),
Copy link
Contributor Author

@lmiller1990 lmiller1990 Feb 7, 2023

Choose a reason for hiding this comment

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

This TODO refers to the other part of this feature, #25680, we will add a function that doe something like:

function addThirdPartyFramework (framework) {
  const resolvedFramework = resolveComponentFrameworkDefinition(framework)
  ctx.coreData.wizard.frameworks.push(resolvedFramework)
}

That will allow third parties to be here, too. They can easily have the correct shape by using the new ComponentFrameworkDefinition interface.

Copy link
Contributor Author

@lmiller1990 lmiller1990 Feb 7, 2023

Choose a reason for hiding this comment

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

vueclivue2
vueclivue3
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These are no longer specific strings, since third parties can be called other things. We lose (some) type safety here... unavoidable.

@lmiller1990 lmiller1990 changed the title refactor: rework component onboarding in launchpad chore: rework component onboarding in launchpad Feb 8, 2023
@@ -152,7 +151,7 @@ export class CodegenActions {
})
}

getWizardFrameworkFromConfig (): WizardFrontendFramework | undefined {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

In general I think we should move away from naming things "Wizard". 🧙 are pretty cool, but it's probably a confusing, considering these are used throughout the entire app, not just in the Launchpad wizard.

We should just call them ComponentFrontendFramework, since that's what they are.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree Wizards are pretty cool

@@ -51,9 +52,21 @@ export class WizardActions {
}
}

setBundler (bundler: WizardBundler | null) {
getNullableBundler (bundler: 'vite' | 'webpack' | null) {
Copy link
Contributor Author

@lmiller1990 lmiller1990 Feb 8, 2023

Choose a reason for hiding this comment

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

So the reason for all the change around bundler is previously we did something like:

export const WIZARD_DEPENDENCY_WEBPACK = {
  type: 'webpack',
  name: 'Webpack',
  package: 'webpack',
  installer: 'webpack',
  description: 'Webpack is a module bundler',
  minVersion: '^=4.0.0 || ^=5.0.0',
} 

supportedBundlers: [WIZARD_DEPENDENCY_WEBPACK]

But for a third party to do this, we'd need to expose the WIZARD_DEPENDENCY_WEBPACK, which is not really ideal or in line with what we currently do and how we define public APIs. In cypress.config, we just do

bundler: 'webpack'

I reworked the internal API (which is also now the public API) to use a string, webpack | vite, instead of the complex WIZARD_DEPENDENCY_WEBPACK object.

Now, it's just

supportedBundlers: ['webpack']

It's way more ergonomic, and mirrors how cypress.config looks. I like this parallel. If we do need the full object, we just use getNullableBundler to grab it.

return this.scaffoldFile(
componentIndexHtmlPath,
chosenFramework.componentIndexHtml(),
chosenFramework.componentIndexHtml?.() ?? defaultComponentIndex(),
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 reason this is now nullable is since third parties CAN provide a custom component-index.html, but don't need to. If they don't, they get our default one.

isDependencyInstalled(dependencies.WIZARD_DEPENDENCY_REACT_DOM, projectPath),
isDependencyInstalled(dependencies.WIZARD_DEPENDENCY_REACT, projectPath),
])
dependencies: (bundler: WizardBundler['type']): Cypress.CypressComponentDependency[] => {
Copy link
Contributor Author

@lmiller1990 lmiller1990 Feb 8, 2023

Choose a reason for hiding this comment

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

This is probably the main change - instead of having these objects declare the metadata and check for the dependencies, they are purely definitions - thus the new and more accurate name, ComponentFrameworkDefinition.

This is the same interface third parties will use, except we omit a few:

type ThirdPartyComponentFrameworkDefinition = Omit<ComponentFrameworkDefinition,
   'glob' | 
  'codeGenFramework' | 
  'supportStatus' |
   'specPattern'
>

Here's why:

  • supportStatus - these are forced to be "community" for third party integrations.
  • 'glob' | 'codeGenFramework' | 'specPattern' - these are all used for Create From Component. We might support this for third parties one day, but not right now. We don't even support it for some first parties, like Svelte, for example.

@lmiller1990 lmiller1990 marked this pull request as ready for review February 8, 2023 06:14
@lmiller1990 lmiller1990 requested a review from a team February 8, 2023 06:14
Copy link
Contributor

@ZachJW34 ZachJW34 left a comment

Choose a reason for hiding this comment

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

Some small comments, works well so far (based on my testing of #25749)

* A semantic, unique identifier. Must begin with `cypress-ct-` for third party implementations.
* @example: 'reactscripts', 'nextjs', 'cypress-ct-solid-js'
*/
type: string
Copy link
Contributor

Choose a reason for hiding this comment

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

Here we say the type must start with cypress-ct-, but the configFramework doesn't have this restriction even though inside of webpack-dev-server/src/devServer.ts we expect it to also have this same restriction. Looks like they should be the same or at least both should share the cypress-ct- prefix

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hm good point, maybe we just expose name in the public API and for third parties, in processFrameworkDefinition, do

configFramework = name

Copy link
Contributor Author

Choose a reason for hiding this comment

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

So configFramework will be @private

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

*
* This is a no-op at runtime - it's purely for type safety.
*/
export function defineComponentFramework (definition: ThirdPartyComponentFrameworkDefinition): ThirdPartyComponentFrameworkDefinition {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should these be exported in the CLI?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, will do

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

]

export type ComponentFrameworkDefinition = Omit<Cypress.ResolvedComponentFrameworkDefinition, 'dependencies'> & {
dependencies: (bundler: WizardBundler['type']) => Cypress.CypressComponentDependency[]
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
dependencies: (bundler: WizardBundler['type']) => Cypress.CypressComponentDependency[]
dependencies: (bundler: 'webpack' | 'vite') => Cypress.CypressComponentDependency[]

Hovering over the type definition for ThirdPartyComponentFrameworkDefinition shows WizardBundler['type']. We should be more explicit for user facing types

packages/scaffold-config/test/unit/fixtures.ts Outdated Show resolved Hide resolved
packages/scaffold-config/src/frameworks.ts Outdated Show resolved Hide resolved
* This is the path to get mount, eg `import { mount } from <mount_module>,
* @example: `cypress-ct-solidjs/src/mount`
*/
mountModule: (projectPath: string) => Promise<string>
Copy link
Contributor

Choose a reason for hiding this comment

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

Mentioned this in the tech-brief but I'm curious what you think of making the ThirdPartyComponentFrameworkDefinition have mountModule: string for simplicity?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good point, I was trying to make the APIs as similar as possible but it's probably not worth it - better to opt for some internal complexity and expose a nicer public API

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We don't need mountModule at all for third parties now... https://github.com/cypress-io/engineering-documentation/pull/71

Since we assume it's named export from the default entry point, we can assume import { mount } from '<package>' is valid.

@@ -152,7 +151,7 @@ export class CodegenActions {
})
}

getWizardFrameworkFromConfig (): WizardFrontendFramework | undefined {
Copy link
Contributor

Choose a reason for hiding this comment

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

I agree Wizards are pretty cool

packages/launchpad/src/setup/SelectFwOrBundler.vue Outdated Show resolved Hide resolved
@lmiller1990 lmiller1990 requested a review from a team February 10, 2023 14:00
Copy link
Contributor

@mike-plummer mike-plummer left a comment

Choose a reason for hiding this comment

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

Solid work 💯 . Left a few code style comments and questions, but looks really good


// Certain properties are not supported for third party frameworks right now, such as ones related to the "Create From" feature.
type ThirdPartyComponentFrameworkDefinition = Omit<ComponentFrameworkDefinition, 'glob' | 'codeGenFramework' | 'supportStatus' | 'specPattern' | 'mountModule' | 'configFramework' | 'type' | 'category'> & {
type: `cypress-ct-${string}`
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, cool, I didn't know you could do this kind of string pattern enforcement with TS 🆒

Copy link
Contributor

Choose a reason for hiding this comment

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

Not a feature supported in older versions of Typescript. Unless we drop versions of typescript that don't support template strings we'll have to go with string

Copy link
Contributor Author

@lmiller1990 lmiller1990 Feb 12, 2023

Choose a reason for hiding this comment

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

Hmm this is a good point - this feature was added in TS 4.1 https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-1.html. Released 2 years ago.

The most popular pre 4.1 version is 3.9.7
with 385k - the latest 4.x has has 6.5M.

We could do

`cypress-ct-${string}` | string

Since our minimum version of TS is 3.4: https://docs.cypress.io/guides/tooling/typescript-support#Install-TypeScript

}

// Certain properties are not supported for third party frameworks right now, such as ones related to the "Create From" feature.
type ThirdPartyComponentFrameworkDefinition = Omit<ComponentFrameworkDefinition, 'glob' | 'codeGenFramework' | 'supportStatus' | 'specPattern' | 'mountModule' | 'configFramework' | 'type' | 'category'> & {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit - might be better to make this an inclusion (Pick) vs exclusion (Omit). Would force us to be more deliberate about what to expose going forward if we add new fields to the internal types

type ThirdPartyComponentFrameworkDefinition = Pick<ComponentFrameworkDefinition, 'name' | 'supportedBundlers' | 'detectors' | 'dependencies' | 'componentIndexHtml'>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Smart, let's do that.

packages/data-context/src/actions/WizardActions.ts Outdated Show resolved Hide resolved
packages/data-context/src/data/ProjectConfigManager.ts Outdated Show resolved Hide resolved

debug('deps are %o', deps)

for (const dep of deps) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could do this in a bit more compact fashion with every:

return deps.every((dep) => {
  debug('detecting %s in %s', dep.dependency.name, this.options.projectRoot)
  const res = await isDependencyInstalled(dep.dependency, this.options.projectRoot)
  return res.satisfied
})

Automatically takes care of ejecting from the loop once when it hits the first false

Copy link
Contributor

Choose a reason for hiding this comment

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

Unless I'm doing something weird I don't think .every/.some supports async callbacks. The callback needs to return a boolean, not a Promise<boolean>.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ugh, totally glossed over the async nature here. Oops.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Still likely possible if we really do not like for loops:

const installed = await Promise.all(deps.map(async (dep) => {
  debug('detecting %s in %s', dep.dependency.name, this.options.projectRoot)
  const res = await isDependencyInstalled(dep.dependency, this.options.projectRoot)
  return res.satisfied
}))

const result = installed.every(Boolean)

for loop seems more sane at this point.

@@ -0,0 +1,15 @@
<template>
<span class="text-warning-600 bg-warning-50 border-warning-300 border-1 border-transparent rounded p-2px ml-4px pr-3px">
Copy link
Contributor

Choose a reason for hiding this comment

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

Have we engaged with Design on the colors here? Just wondering if we want to use the same "warning style" color for community as we do for alpha support

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We have, I'll push the change now.

https://cypressio.slack.com/archives/C3WD9SGKW/p1675836497144059

Jade-100 is the color.

packages/launchpad/src/setup/SelectFwOrBundler.vue Outdated Show resolved Hide resolved
packages/launchpad/src/setup/SelectFwOrBundler.vue Outdated Show resolved Hide resolved
packages/scaffold-config/src/frameworks.ts Outdated Show resolved Hide resolved
}

if (isThirdPartyDefinition) {
const def = definition as Cypress.ThirdPartyComponentFrameworkDefinition
Copy link
Contributor

Choose a reason for hiding this comment

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

Totally up to you, but we could avoid this cast and the extra def variable by using a type guard:

function isThirdPartyDefinition (definition: Cypress.ComponentFrameworkDefinition | Cypress.ThirdPartyComponentFrameworkDefinition): definition is Cypress.ThirdPartyComponentFrameworkDefinition {
  return definition.type.startsWith('cypress-ct')
}

const isThirdParty = isThirdPartyDefinition(definition)

Copy link
Contributor Author

@lmiller1990 lmiller1990 Feb 12, 2023

Choose a reason for hiding this comment

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

Oh nice... let me try this, but if it's as simple as it looks here, this is better.


// Certain properties are not supported for third party frameworks right now, such as ones related to the "Create From" feature.
type ThirdPartyComponentFrameworkDefinition = Omit<ComponentFrameworkDefinition, 'glob' | 'codeGenFramework' | 'supportStatus' | 'specPattern' | 'mountModule' | 'configFramework' | 'type' | 'category'> & {
type: `cypress-ct-${string}`
Copy link
Contributor

Choose a reason for hiding this comment

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

Not a feature supported in older versions of Typescript. Unless we drop versions of typescript that don't support template strings we'll have to go with string

const thirdPartyFrameworkDefinitionInvalidStrings = defineComponentFramework({
type: 'cypress-not-cy-wrong-prefix', // $ExpectError
name: 'Third Party',
category: 'template', // $ExpectError - only library supported for third party definitions
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
category: 'template', // $ExpectError - only library supported for third party definitions
// only library supported for third party definitions
category: 'template', // $ExpectError

Looks like the syntax for dtslint is pretty strict, the extra comment following the assertion messes with this check


debug('deps are %o', deps)

for (const dep of deps) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Unless I'm doing something weird I don't think .every/.some supports async callbacks. The callback needs to return a boolean, not a Promise<boolean>.

packages/data-context/src/actions/WizardActions.ts Outdated Show resolved Hide resolved
packages/data-context/src/data/ProjectConfigManager.ts Outdated Show resolved Hide resolved
packages/graphql/schemas/schema.graphql Outdated Show resolved Hide resolved
packages/launchpad/src/setup/SelectFwOrBundler.vue Outdated Show resolved Hide resolved
packages/launchpad/src/setup/SelectFwOrBundler.vue Outdated Show resolved Hide resolved
packages/scaffold-config/src/frameworks.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@mike-plummer mike-plummer left a comment

Choose a reason for hiding this comment

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

Zach addressed most of my feedback. There are a few outstanding comments but those are non-blocking so I will approve assuming they will get addressed/answered as part of the feature work

@lmiller1990 lmiller1990 merged commit 3ad71ea into feature/ct-public-api Feb 13, 2023
@lmiller1990 lmiller1990 deleted the lmiller/ct-public-api-refactor branch February 13, 2023 00:00
lmiller1990 added a commit that referenced this pull request Feb 21, 2023
* chore: rework component onboarding in launchpad (#25713)

* chore: refactoring and types

* rework source of frameworks

* revert rename

* fix tests

* fix more tests

* types

* update code

* use same public API internally

* rename interfaces

* rename

* work on dev server api

* fix types

* fix test

* attempt to support getDevServerConfig

* tests

* add function to define framework [skip ci]

* rework a lot of types

* fix test

* update tests and types

* refactor

* revert changes

* lint

* fix test

* revert

* remove

* add "community" label [skip ci]

* refactor

* types

* lint

* fix bug

* update function name

* address feedback

* improve types with Pick

* refactor using type guard

* correct label

---------

Co-authored-by: Zachary Williams <ZachJW34@gmail.com>

* chore: typing error

* feat: scan for 3rd party ct plugins (#25749)

* chore: refactoring and types

* rework source of frameworks

* revert rename

* fix tests

* fix more tests

* types

* update code

* use same public API internally

* rename interfaces

* rename

* work on dev server api

* fix types

* fix test

* attempt to support getDevServerConfig

* tests

* add function to define framework [skip ci]

* rework a lot of types

* fix test

* update tests and types

* refactor

* revert changes

* lint

* fix test

* revert

* remove

* add "community" label [skip ci]

* refactor

* types

* lint

* fix bug

* update function name

* address feedback

* feat: scan for 3rd party ct plugins

* add e2e test

* unit tests [run ci]

* tweak resolution

* rebase, address comments

* fix windows paths

* remove .gitignore

* fix test

---------

Co-authored-by: Lachlan Miller <lachlan.miller.1990@outlook.com>

* lint config

* spacing

* try fix race cond

* fix import error

* build binary

* try update snapshot

* try using require

* support namespaced definitions (#25804)

* remove category

* add icon prop

* support esm -> cjs compiled typescript

* fix test

* misc: add CTA footer to launchpad framework dropdown (#25831)

* remove test project dependencies

* rebase

* windows

* windows again

* add changelog entry

* changelog

* revert workflow

* remove worklfow

---------

Co-authored-by: Zachary Williams <ZachJW34@gmail.com>
Co-authored-by: Adam Stone-Lord <adams@cypress.io>
mjhenkes added a commit that referenced this pull request Feb 21, 2023
* fix: update newProject ref when switching between organizations in SelectCloudProjectModal (#25730)

* chore: debug page tooltip distance and artifact border (#25727)

* misc: debug page tooltip distance and artifact border

* add changelog entry

* fix CT test

* fix: Improve error handling around calls to `this.next` in middleware (#25702)

* chore: update changelog validation example (#25742)

* misc: improve debug loading text wrap responsiveness (#25703)

* misc: Increase max failures in IATR badge to 99 (#25737)

* chore: exclude collaborator issues/PRs from triage project (#25769)

* feat: add --auto-cancel-after-failures flag (#25237)

Co-authored-by: Emily Rohrbough <emilyrohrbough@users.noreply.github.com>
Co-authored-by: Matt Schile <mschile@cypress.io>
Co-authored-by: Ryan Pei <ryanppei@gmail.com>
Co-authored-by: Emily Rohrbough <emilyrohrbough@yahoo.com>

* chore: Update v8 snapshot cache (#25592)

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* Update update_v8_snapshot_cache.yml

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

* chore: updating v8 snapshot cache

---------

Co-authored-by: cypress-bot[bot] <2f0651858c6e38e0+cypress-bot[bot]@users.noreply.github.com>
Co-authored-by: Ryan Manuel <ryanm@cypress.io>
Co-authored-by: cypress-bot[bot] <47117332+cypress-bot[bot]@users.noreply.github.com>

* fix: implement new graphql fields for spec counts (#25757)

Co-authored-by: Stokes Player <stokes@cypress.io>
Co-authored-by: Mike Plummer <mike-plummer@users.noreply.github.com>

* feat: Bundle cy.origin() dependencies at runtime (#25626)

Co-authored-by: cypress-bot[bot] <2f0651858c6e38e0+cypress-bot[bot]@users.noreply.github.com>
Co-authored-by: Ryan Manuel <ryanm@cypress.io>

* chore: remove zenhub from release process (#25701)

Co-authored-by: Matt Schile <mschile@cypress.io>

* feat: add Cypress.Commands.overwriteQuery (#25674)

* feat: add Cypress.Commands.overwriteQuery

Co-authored-by: Emily Rohrbough <emilyrohrbough@users.noreply.github.com>
Co-authored-by: Zach Bloomquist <git@chary.us>

* fix: spawn child process with process.env in macOS arm64 (#25753)

Co-authored-by: Matt Schile <mschile@cypress.io>
Co-authored-by: Emily Rohrbough <emilyrohrbough@users.noreply.github.com>
Co-authored-by: Zach Bloomquist <github@chary.us>

* chore: lint system tests in CI (#25673)

* fix: Suppress filesystem errors during glob search (#25774)

* chore: issue with ts-loader missing in binary and problematic esbuild norewrite construct (#25797)

* chore: update changelog linting (#25809)

* docs(guides): add more detail to code-signing (#25794)

Co-authored-by: Emily Rohrbough <emilyrohrbough@users.noreply.github.com>

* chore: update workflows.yml to include the v8 snapshot update branch (#25784)

Co-authored-by: cypress-bot[bot] <+cypress-bot[bot]@users.noreply.github.com>

* chore: internal request preflight (#25772)

---------

Co-authored-by: Emily Rohrbough <emilyrohrbough@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: cypress-bot[bot] <2f0651858c6e38e0+cypress-bot[bot]@users.noreply.github.com>
Co-authored-by: Ryan Manuel <ryanm@cypress.io>
Co-authored-by: Matt Henkes <mjhenkes@gmail.com>
Co-authored-by: Zach Bloomquist <git@chary.us>

* chore: bump for 12.6.0 release (#25812)

* chore: release @cypress/webpack-batteries-included-preprocessor-v2.4.0

[skip ci]

* chore: release @cypress/webpack-preprocessor-v5.17.0

[skip ci]

* test: skip flaky GitDataSource test (#25825)

* chore: making our add-to-triage-board workflow reusable within the Cypress-io org (#25820)

* chore: Making our add to triage workflow callable from other projects inside the Cypress-io org in Github

* chore: updated cypress-example-kitchensink version (#25828)

* fix: duplicate and expired cookies (#25761)

* chore: add regression tests for duplicate cookies and bad expiry times

* avoid prepending domain with dot for cookies that are set with the server side jar. This is to avoid the cookie being duplicated if it is set or overridden in a different context (request that can actually set the cookie or via document.domain)

* feat: use cookie.toString() in the cookie patch to more accurately set cookies on the document, which should include other properties besides key=value

* fix: add logic to handle expired cookies in the document.cookie patch, as well as in CDP

* chore: build binary for cookie fixes for users to test

* chore: change name of fixture to something more accurate

* chore: comment why we are using the toughCookie toString method in the patch

* [run ci]

* chore: add changelog entry

* [run ci]

* fix: revert back to key=value when getting document.cookie as those are the only values are displayed (oversight on my end)

* [run ci]

* chore: make compatible with cypress.require

* fix: add tests for hostOnly/non hostOnly cookies to make sure property gets sent up to automation client correctly. No longer need custom cookie prop to determine destination

* [run ci]

* fix: stale unit test

* chore: adjust comments

* [run ci]

* fix: bad domain logic

* [run ci]

* chore: remove irrelevant comment

* [run ci]

* fix: adjust cookie login text to spec hostOnly cookie within the cookie patch. This should yield the same behavior as we are bound to same origin within the spec bridge

* [run ci]

* [run ci]

* fix: allow for cookies on request of same key to take precedence over cookies in the jar, regardless of how many hierachy cookies exist in the jar

* chore: fix cookie misc tests for cy.origin (dont run cy.origin)

* [run ci]

* chore: skip misc cookie tests in webkit as headless behavior doesn't clear cookies between tests correctly

* Revert "fix: allow for cookies on request of same key to take precedence over cookies in the jar, regardless of how many hierachy cookies exist in the jar"

This reverts commit 17de188.

* [run ci]

* chore: split changelog entry into two parts

* chore: update logic to remove else statement and add comments

* [run ci]

* chore: readd windows snapshot branch in workflows

* [run ci]

* chore: fix workflows from bad merge

* [run ci]

* Revert "chore: split changelog entry into two parts"

This reverts commit 4352ef5.

* [run ci]

* fix: Fix type definitions for cy.reload() (#25779)

Co-authored-by: Emily Rohrbough <emilyrohrbough@users.noreply.github.com>

* misc: Debug header updates (#25823)

* fix: allow running tests outside Vite project root folder (#25801)

* fix: allow running tests outside Vite project root folder

* update snapshots

* add changelog entry

---------

Co-authored-by: Lachlan Miller <lachlan.miller.1990@outlook.com>

* fix: mount component in [data-cy-root] (#25807)

* fix(angular): mount component in [data-cy-root]

* fix e2e test

* add changelog entry

* changelog [skip ci]

* changelog

---------

Co-authored-by: Lachlan Miller <lachlan.miller.1990@outlook.com>

* chore: updating add to triage baord github action to use org secret (#25868)

* chore: updating add to triage board github action to use org secret

* chore: release @cypress/angular-v2.0.2

[skip ci]

* chore: release @cypress/vite-dev-server-v5.0.3

[skip ci]

* chore: Update v8 snapshot cache (#25822)

Co-authored-by: cypress-bot[bot] <+cypress-bot[bot]@users.noreply.github.com>
Co-authored-by: Ryan Manuel <ryanm@cypress.io>

* feat: support host only cookies (#25853)

* feat: allow setCookie API to take a hostOnly option

* chore: add jsdoc/typescript description to render to users

* chore: add changelog entry

* [run ci]

* chore: fix types

* chore: fix cookie login tests

* chore: update e2e cookie system tests

* [run ci]

* chore: fix cookie command tests. localhost cookies are calculated as hostOnly, which is consistent with how cypress works today

* chore: fix system tests for cookies.

* [run ci]

* chore: fix system tests

* chore: skip hostOnly assertions in webkit (for now)

* [run ci]

* chore: add property definitions to setCookieOptions

* [run ci]

* chore: add comments to hostOnly prop in firefox when setting a cookie

* fix(webpack-dev-server): touch component-index during onSpecsChange to avoid writing to app file (#25861)

* testing: try disabling uTimesSync and see what happens

* build binaries [run ci]

* fix: touch component index file instead of browser.js

* build binaries [run ci]

* update test

* fix test

* add test for custom HTML file in config

* use existing component index in webpack-dev-server unit tests

---------

Co-authored-by: Lachlan Miller <lachlan.miller.1990@outlook.com>

* chore: release @cypress/webpack-dev-server-v3.2.4

[skip ci]

* chore: improve types for server automation cookie client (#25836)

* chore: improve types for automation cookies

* [run ci]

* fix: the cookie_behavior tests by syncing cookies immediately if … (#25855)

* fix: fix the cookie_behavior tests by syncing cookies immediately if the application is already stable

* chore: add changelog entry

* [run ci]

* chore: address comments from code review

* feat: Public API for CT Framework Definitions (#25780)

* chore: rework component onboarding in launchpad (#25713)

* chore: refactoring and types

* rework source of frameworks

* revert rename

* fix tests

* fix more tests

* types

* update code

* use same public API internally

* rename interfaces

* rename

* work on dev server api

* fix types

* fix test

* attempt to support getDevServerConfig

* tests

* add function to define framework [skip ci]

* rework a lot of types

* fix test

* update tests and types

* refactor

* revert changes

* lint

* fix test

* revert

* remove

* add "community" label [skip ci]

* refactor

* types

* lint

* fix bug

* update function name

* address feedback

* improve types with Pick

* refactor using type guard

* correct label

---------

Co-authored-by: Zachary Williams <ZachJW34@gmail.com>

* chore: typing error

* feat: scan for 3rd party ct plugins (#25749)

* chore: refactoring and types

* rework source of frameworks

* revert rename

* fix tests

* fix more tests

* types

* update code

* use same public API internally

* rename interfaces

* rename

* work on dev server api

* fix types

* fix test

* attempt to support getDevServerConfig

* tests

* add function to define framework [skip ci]

* rework a lot of types

* fix test

* update tests and types

* refactor

* revert changes

* lint

* fix test

* revert

* remove

* add "community" label [skip ci]

* refactor

* types

* lint

* fix bug

* update function name

* address feedback

* feat: scan for 3rd party ct plugins

* add e2e test

* unit tests [run ci]

* tweak resolution

* rebase, address comments

* fix windows paths

* remove .gitignore

* fix test

---------

Co-authored-by: Lachlan Miller <lachlan.miller.1990@outlook.com>

* lint config

* spacing

* try fix race cond

* fix import error

* build binary

* try update snapshot

* try using require

* support namespaced definitions (#25804)

* remove category

* add icon prop

* support esm -> cjs compiled typescript

* fix test

* misc: add CTA footer to launchpad framework dropdown (#25831)

* remove test project dependencies

* rebase

* windows

* windows again

* add changelog entry

* changelog

* revert workflow

* remove worklfow

---------

Co-authored-by: Zachary Williams <ZachJW34@gmail.com>
Co-authored-by: Adam Stone-Lord <adams@cypress.io>

* chore: release @cypress/webpack-dev-server-v3.3.0

[skip ci]

* fix: Add missing error message when `req.continue` is used incorrectly (#25884)

---------

Co-authored-by: Adam Stone-Lord <adams@cypress.io>
Co-authored-by: Zachary Williams <ZachJW34@gmail.com>
Co-authored-by: Mike Plummer <mike-plummer@users.noreply.github.com>
Co-authored-by: Matt Schile <mschile@cypress.io>
Co-authored-by: Alejandro Estrada <estrada9166@gmail.com>
Co-authored-by: Emily Rohrbough <emilyrohrbough@users.noreply.github.com>
Co-authored-by: Ryan Pei <ryanppei@gmail.com>
Co-authored-by: Emily Rohrbough <emilyrohrbough@yahoo.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: cypress-bot[bot] <2f0651858c6e38e0+cypress-bot[bot]@users.noreply.github.com>
Co-authored-by: Ryan Manuel <ryanm@cypress.io>
Co-authored-by: cypress-bot[bot] <47117332+cypress-bot[bot]@users.noreply.github.com>
Co-authored-by: Mark Noonan <mark@cypress.io>
Co-authored-by: Stokes Player <stokes@cypress.io>
Co-authored-by: Chris Breiding <chrisbreiding@users.noreply.github.com>
Co-authored-by: Zach Bloomquist <git@chary.us>
Co-authored-by: willmsC <50909991+willmsC@users.noreply.github.com>
Co-authored-by: Zach Bloomquist <github@chary.us>
Co-authored-by: cypress-bot[bot] <+cypress-bot[bot]@users.noreply.github.com>
Co-authored-by: Tim Griesser <tgriesser10@gmail.com>
Co-authored-by: Matt Henkes <mjhenkes@gmail.com>
Co-authored-by: semantic-release-bot <semantic-release-bot@martynus.net>
Co-authored-by: Ben M <benm@cypress.io>
Co-authored-by: Bill Glesias <bglesias@gmail.com>
Co-authored-by: Podles <78863563+podlesny-j@users.noreply.github.com>
Co-authored-by: Paolo Caleffi <p.caleffi@dreamonkey.com>
Co-authored-by: Lachlan Miller <lachlan.miller.1990@outlook.com>
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.

3 participants