Issue number: resolves#20053
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
There are a few methods that that are missing for the menu in the
Angular packages. This leads to users to not being able to use methods
like `isAnimating()`.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The missing methods have been added by implementing `MenuControllerI`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: 7.5.8-dev.11701461830.1be851fd
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The labeler action is currently failing:
https://github.com/ionic-team/ionic-framework/actions/runs/7090913880/job/19298918578?pr=28622.
This is happening due to a breaking change in v5 of the action.
We currently pull from `main` for this action so we are now receiving v5
of the action:
fe3c3d500a/.github/workflows/label.yml (L16)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- This PR updates the action explicitly to v5 so we don't unexpectedly
take on breaking changes
- This PR also updates the labeler yaml file to account for the v5
breaking changes
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: Related to #18132
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The documentation about the `autofocus` prop is unclear and does not
accurately reflect how it actually works across browsers and devices.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The documentation for `autofocus` and `setFocus` are more detailed.
- The documentation links to the relevant page in the docs.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: Resolves#26524
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## Definitions
**Parameterized routes**: A route that includes one or more variables in
the path segments, such as `/form/:index`.
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
When an application routes from a parameterized route, to an
intermediary route, to the same parameterized route, but with a
different value/url, Ionic's routing logic is incorrectly reusing the
view item from the first instance of the parameterized route instead of
calculating that the matched path is different. This results in the
wrong view item being recycled and rendered.
Another way of representing it:
- User navigates to `/form/0` which resolves `FormPage`
- User enters `0` into the form and submits the form
- User navigates to `/link`, which resolves `LinkPage`
- User navigates to `/form/1`, which resolves `FormPage`
- However, instead of creating a new instance of `FormPage` it is
reusing the instance of `FormPage` from `/form/0` which includes the
form having `0` in the input.
- The user now sees a "new view", but with cached data in the form.
This is not expected or desired.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Ionic's routing logic will validate if the entering view item matches
the match route data before reusing it. This results in new instances of
the view item being constructed when using parameterized routes.
https://github.com/ionic-team/ionic-framework/assets/13732623/e7e3d03f-2848-4429-9f60-9074d0761e45
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev-build: `7.5.8-dev.11701383555.17254408`
Issue number: resolves#28611
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
It's not possible to pass props that are not camelCase to the `IonNav`
component.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- It is now possible to set a props with kebab-case instead of camelCase
(for example, `root-params` instead of `rootParams`)
## Does this introduce a breaking change?
- [ ] Yes
- [X] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
⚠️ This is my first PR for ionic so I hope I didn't miss important steps
into the process. I also checked on my project that the fix is working
well. Thank you! 🙂
---------
Co-authored-by: Sean Perkins <sean@ionic.io>
Issue number: resolves#28524
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Watchers in Stencil are constructed sometime between `connectedCallback`
and `componentDidLoad`. If a property is set/changed during that time it
is possible for the callback associated with the watcher to not fire
because the watcher has not been setup yet. This is most often with
`dist-custom-elements` and frameworks such as Angular when using a
binding (i.e. `[trigger]` instead of `trigger`)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The trigger callback associated with the watcher is manually called in
`componentDidLoad` for each overlay.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.5-dev.11699974376.13a15397`
Note: This is a timing related bug due to a behavior in Stencil, so I
did not write automated tests. However, I manually verified that this
issue a) reproduces on `main` and b) is fixed with this dev build for
each overlay component.
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Testing dark mode is manual per test in Playwright. Ionic developer
needs to setup the variables and assign them to a selector that applies
in the class.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- The `.setContent` API will now work with a new config option to test
dark mode automatically without additional configuration/test set-up.
- Default theme is no theme (fallback theme)
- Screenshot names and test titles remain the same for all existing
tests. Only tests that opt into a theme will be pre-pended with `-dark`
or `-light` (as an example for current themes).
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
When using `.setContent`, the initial page template is lacking key
metadata that will result in AXE violations.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds a default `lang` to the `html` document root
- Adds a default `title` tag
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
It is possible to navigate the columns of a disabled Datetime with
`prefer-wheel` via the keyboard.
https://github.com/ionic-team/ionic-framework/assets/14926794/9c9dafc4-4b77-45a6-a276-70201c5c3ea5
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Picker Column Internal has a disabled state that disables the full
column
- When a Datetime is disabled with `prefer-wheel`, the columns in the
Datetime will be disabled
- It is no longer possible to navigate the wheels in a disabled Datetime
via the keyboard
Comparison of native & Ionic components:
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#28494
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The appearance of the input is being set to `none` which clears the
browser appearance settings for height on the control. This results in
the `<input type="date" />` to render without a height.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Minimum height is assigned to the alert input, forcing it to render at
it's expected height
- Date input renders correctly in Mobile Safari
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
We have screenshots for this component, but Playwright runs an emulation
of Mobile Safari that does not reproduce this issue that is only present
on device. There for we cannot write a test on this change.
---------
Co-authored-by: ionitron <hi@ionicframework.com>
Issue number: resolves#28385
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Overlay controllers do not register their respective overlays
components. This results in the overlay not appearing.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Each standalone overlay controller manually calls
`defineCustomElement` for their respective overlay component to ensure
the component is loaded/registered.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.6-dev.11700492285.1581ed02`
Issue number: Resolves#28514
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
When using the `@ionic/angular` schematic in an Angular 17 project (`ng
add @ionic/angular`), developers will receive an error preventing the
schematic from running.
Additionally, the previous implementations of the schematic are out of
sync with the current state of the Ionic starters:
- `variables.css` is empty and missing Ionic's defaults
- `ionic.config.json` is not created
- Schematic does not have support for module vs. standalone projects.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `ng add @ionic/angular` works with Angular 17 projects
- `ng add @ionic/angular` has fallback behavior for Angular 16 projects
using `AppModule`
- Schematics now includes the proper `variables.css` from Ionic starters
- Ionicons assets will no longer be copied when being added to a
standalone project
- Refactors a majority of the implementation to use the utilities that
come directly from `@angular-devkit/schematics` and
`@schematics/angular`.
- Sets the `@ionic/angular-toolkit` CLI configuration and schematics
configuration in the `angular.json`
- Creates missing `ionic.config.json`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev-build: `7.5.5-dev.11700239837.1925bbdb`
To test this PR:
1. Install Angular CLI v17 - `npm install -g @angular/cli@17`
2. Create a new project - `ng new angular-17`
3. Use the dev-build: - `ng add
@ionic/angular@7.5.5-dev.11700239837.1925bbdb`
4. Confirm the prompts
5. Validate that `provideIonicAngular({})` is added to the
`app.config.ts`
6. Validate that `ionic.config.json` was created
7. Validate that `angular.json` was updated with the
`@ionic/angular-devkit` configurations
Now verify legacy behavior:
1. Install Angular CLI v16 - `npm install -g @angular/cli@16`
2. Create a new project - `ng new angular-16`
3. Use the dev-build - `ng add
@ionic/angular@7.5.5-dev.11700239837.1925bbdb`
4. Confirm the prompts
5. Validate that `IonicModule.forRoot({})` is added to the
`app.module.ts`
8. Validate the ionicons glob pattern is added to the `angular.json`
9. Validate the `ionic.config.json` was created
10. Validate the `angular.json` was updated with the
`@ionic/angular-devkit` configurations
Issue number: resolves#28548
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Datetime was not scrolling at all when the `value` prop was changed
programmatically. This was due to some logic we had in
`componentDidRender` to work around a WebKit bug which was causing the
scroll position to be moved back to where it was prior to setting the
`value` prop. This caused the scroll position to never move.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Datetime scrolls to the new value when `value` is updated
programmatically even if `min` is set.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Dev build: `7.5.6-dev.11700169088.140f3e6a`
Co-authored-by: amandaejohnston
<amandaejohnston@users.noreply.github.com>
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
As a takeaway from our learning session about a menuController bug in
Ionic Angular, the team would like to update our other providers to use
the same architecture as the menuController to prevent this kind of
issue from happening again in the future.
We also noticed that the common provider does not provide much value and
it's easier to just have two separate implementations in `src` and
`standalone`. (There wasn't much code we could de-duplicate)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the common loading provider in favor of separate ones in
src/standalone
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Type checking inside of the Stencil unit tests have been disabled for a
long time. This has resulted in a difficult developer experience and
numerous issues (both types and implementation) within our unit tests.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Type checking is now enabled for all Stencil unit tests
- Tests have been updated to resolve type errors and implementation
errors
- Many `as any` casts were introduced, as many legacy tests test invalid
configurations of functions that require it (for example passing
`undefined` to an argument that cannot be `undefined`).
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
To test this PR you can checkout the branch locally. Install
dependencies in the `/core` directory to make sure you are on at least
`@stencil/core@4.7.2`.
Opening either a `.spec.ts` or `.spec.tsx` file, validate that your IDE
detects types and can provide auto completions for jest global types.
If you desire, you can provide an invalid type and try building the
project - you will observe the build will fail due to the invalid type.
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
As a takeaway from our learning session about a menuController bug in
Ionic Angular, the team would like to update our other providers to use
the same architecture as the menuController to prevent this kind of
issue from happening again in the future.
We also noticed that the common provider does not provide much value and
it's easier to just have two separate implementations in `src` and
`standalone`. (There wasn't much code we could de-duplicate)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the common alert provider in favor of separate ones in
src/standalone
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#23977
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The MD Alert on tablet dimensions does not match the MD spec
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- MD Alert now follows the MD spec for tablet dimensions
- Added tablet and mobile viewport mixins for alert and the card modal.
(There should be no visual diffs for the card modal)
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
This supersedes https://github.com/ionic-team/ionic-framework/pull/27462
since I needed to add new screenshot tests. The author of that PR has
been given co-author credit here.
---------
Co-authored-by: GlenOttley <GlenOttley@users.noreply.github.com>
Co-authored-by: ionitron <hi@ionicframework.com>
Co-authored-by: Brandy Carney <brandyscarney@users.noreply.github.com>
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
As a takeaway from our learning session about a menuController bug in
Ionic Angular, the team would like to update our other providers to use
the same architecture as the menuController to prevent this kind of
issue from happening again in the future.
We also noticed that the common provider does not provide much value and
it's easier to just have two separate implementations in `src` and
`standalone`. (There wasn't much code we could de-duplicate)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the common picker provider in favor of separate ones in
src/standalone
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Ionic Framework migrated to using `eslint` for linting all of our
projects awhile ago. However we left around an unused tslint config file
in the Angular project by accident.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removes the unused tslint configuration file
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Type checking is disabled in the `standalone/` directory of the angular
project.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Enables type checking in the standalone directories.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Our Angular E2E tests are brittle because they rely on arbitrary
`cy.wait` calls to account for asynchronous routing. This leads to flaky
tests on CI and seemingly random test failures when we make adjustments
to the Ionic Anguar routing integration (see:
https://github.com/ionic-team/ionic-framework/pull/28188)
Additionally, our test execution for the navigation tests is quite slow
because transitions are enabled. As a result, we need to wait hundreds
of ms per test just for the transitions to finish.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Updated the `testStack` command to use a new `getStack` [Cypress
query](https://docs.cypress.io/api/cypress-api/custom-queries). These
queries come with automatic retrying built-in. By leveraging this query
in the `testStack` command, we can avoid the arbitrary waits.
- Added `ionic:_testing=true` query strings to the navigation tests.
This causes Ionic to disable any transitions so the tests execute
faster.
- Removed most of the arbitrary `cy.wait` calls. I kept the swipe to go
back `cy.wait` -- I wasn't quite sure how to reduce flakiness on that
one.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Bumps
[@stencil/vue-output-target](https://github.com/ionic-team/stencil-ds-output-targets)
from 0.8.6 to 0.8.7.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/ionic-team/stencil-ds-output-targets/commits">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: resolves#28506
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
ion-accordion-group would not set the value when using it as a Angular
standalone component and data binding:
``` html
<ion-accordion-group #accordionGroup [value]="fromValue">
<ion-accordion value="turtles">
<ion-item slot="header" color="light">
<ion-label>First Accordion</ion-label>
</ion-item>
<div class="ion-padding" slot="content">First Content</div>
</ion-accordion>
<ion-accordion value="second">
<ion-item slot="header" color="light">
<ion-label>Second Accordion</ion-label>
</ion-item>
<div class="ion-padding" slot="content">Second Content</div>
</ion-accordion>
</ion-accordion-group>
```
The problem here is Angular is setting the value of the accordion group
after the component has been initialized (but not loaded) and before the
component watchers are setup, so
[valueChanged](d69ad43482/core/src/components/accordion-group/accordion-group.tsx (L78))
does not fire automatically.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Run valueChanged() in componentDidLoad().
-
-
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
---------
Co-authored-by: Mohamed Ben Makhlouf <benmakhlouf@softcatalyst.com>
Co-authored-by: Liam DeBeasi <liamdebeasi@users.noreply.github.com>
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
There is no Angular v17 test app.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
There is an Angular v17 test app.
New overrides:
- angular.json: `browserTarget` was changed to `buildTarget` and to
replace `@nguniversal` with `@angular/ssr` and
`@angular-devkit/build-angular`
- server.ts: Replace uses of `@nguniversal` with `@angular/ssr`
New change to base:
- polyfills.ts: Import
[changed](https://github.com/angular/angular/blob/main/CHANGELOG.md#zonejs)
from `import 'zone.js/dist/zone';` (this change is supported for all
versions of Angular that we support, so should be changed in the base
file)
All other files were duplicated from their v16 counterparts.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
While evaluating step colors for high contrast themes I discovered that
this code is not actually applied anywhere.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Remove unused code
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: resolves#28356
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
`ion-radio-group` would not set the radio value when using it as a
Angular standalone component and data binding:
```html
<ion-radio-group [value]="fromValue">
<ion-radio value="dogs">Dogs</ion-radio><br />
<ion-radio value="cats">Cats</ion-radio><br />
<ion-radio value="turtles">Turtles</ion-radio><br />
<ion-radio value="fish">Fish</ion-radio><br />
</ion-radio-group>
```
This is happening because the value is set before the [value
watcher](c5dd622bbe/core/src/components/radio-group/radio-group.tsx (L34))
has been configured. The event, `ionValueChange`, does not get
[dispatched](c5dd622bbe/core/src/components/radio-group/radio-group.tsx (L37)).
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
Run `valueChanged()` in `componentDidLoad()`.
- `valueChanged()` function is tied to the [value
watcher](c5dd622bbe/core/src/components/radio-group/radio-group.tsx (L34))
so it will
[dispatch](c5dd622bbe/core/src/components/radio-group/radio-group.tsx (L37))
the `ionValueChange`.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
In our testing, we observed that the issue described below only occurs
when assigning a value to the radio group within the primary content,
such as rendering within the app component template.
When the template is isolated to a route, the value is assigned
correctly. To address this issue, we need to ensure that the watcher is
called after the component has finished loading, allowing the emit to be
dispatched correctly.
Dev build: 7.5.4-dev.11699404450.136700d7
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `GestureController` provider does not use the correct underlying
instance of the utilities from either the lazy or custom elements build,
depending on if the developer is using `@ionic/angular` or
`@ionic/angular/standalone`. It will always use the lazy instance.
This applied to the `createGesture` function.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `GestureController` uses the instance of the utilities based on it's
implementation type, e.g. `@ionic/angular/standalone` uses the custom
elements build with the utilities from `@ionic/core/components`.
- `@ionic/angular` and `@ionic/angular/standalone` now export their own
specific implementation of `GestureController`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: Internal
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
The `AnimationController` does not use the correct underlying instance
of the utilities from either the lazy or custom elements build,
depending on if the developer is using `@ionic/angular` or
`@ionic/angular/standalone`. It will always use the lazy instance.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- `AnimationController` uses the instance of the utilities based on it's
implementation type, e.g. `@ionic/angular/standalone` uses the custom
elements build with the utilities from `@ionic/core/components`.
- `@ionic/angular` and `@ionic/angular/standalone` now export their own
specific implementation of `AnimationController`
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
Ionic was re-exporting the `AnimationController` from both
`@ionic/angular` and `@ionic/angular/standalone` entry points.
Developers will not need to update their implementations or change
import paths to take advantage of this change.
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: #
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
Ionic Framework uses Jest 27. Previously, this was due to a limitation
of Stencil. As of Stencil v4.7.0, this limitation no longer exists & the
Framework can upgrade to the latest version of Jest.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
There was a top level dependency on `@jest/core` that I could not find
to be used anywhere. This dependency is included in `jest` by default,
and has been removed as a top level/`package.json` dependency.
Otherwise, all jest packages have been upgraded to jest v29. This is two
major version bumps and a switch to the jest-circus runtime (instead of
jest-jasmine2).
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
There is some inherent risk of _something_ breaking when someone like me
who doesn't work on this project day-to-day bumps packages. I did this
as a part of testing Jest 29 when implementing its support in Stencil
and thought "Well, why not?". Feel free to reject this PR if you feel
it's not worth the risk/effort at the moment.
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
## What is the current behavior?
As a takeaway from our learning session about a menuController bug in
Ionic Angular, the team would like to update our other providers to use
the same architecture as the menuController to prevent this kind of
issue from happening again in the future.
We also noticed that the common provider does not provide much value and
it's easier to just have two separate implementations in `src` and
`standalone`. (There wasn't much code we could de-duplicate)
## What is the new behavior?
- Removed the common toast provider in favor of separate ones in
src/standalone
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
## Other information
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
This is part of my work for hack day, but I wanted to tackle the
following problems:
1. There is no easy way to have angular, angular-server, vue,
vue-router, react, and react-router automatically recompile when you
make a change. Right now you have to manually run `npm run build` every
time you make a change.
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Adds `npm run build.watch` to let developers easily watch for changes
in each project.
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
Issue number: N/A
---------
<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->
<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->
As a takeaway from our learning session about a menuController bug in
Ionic Angular, the team would like to update our other providers to use
the same architecture as the menuController to prevent this kind of
issue from happening again in the future.
We also noticed that the common provider does not provide much value and
it's easier to just have two separate implementations in `src` and
`standalone`. (There wasn't much code we could de-duplicate)
## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->
- Removed the common modal provider in favor of separate ones in
src/standalone
We already have test coverage for the modalController, so I did not add
new ones
## Does this introduce a breaking change?
- [ ] Yes
- [x] No
<!-- If this introduces a breaking change, please describe the impact
and migration path for existing applications below. -->
## Other information
<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->
