* chore(e2e): WIP to add files needed for app-scripts
* chore(e2e): WIP one e2e test building but with errors
* chore(e2e): move e2e.prod to working with app-scripts
move shared functions into util, add support for debug flag when
running e2e.prod / demos.prod which gets passed to app-scripts
* chore(build): fix app-scripts build for all e2e and demos
* chore(e2e): update ionic-angular import path
* chore(build): update dev paths to work with prod
* chore(e2e): get watch working with e2e prod
* docs(scripts): update README for running e2e and demos
closes#8411closes#10023
Internal refactor completed in order to improve tree shaking and dead
code removal. The public API, with an exception to ion-slides, has
stayed the same. However, internally many changes were required so
bundlers could better exclude modules which should not be bundled.
Ultimately most changes resorted to removing references to `window` or
`document`, or a module that referenced one of those.
BREAKING CHANGES
ion-slides was refactored to remove the external dependencies, and
rewritten in TypeScript/ES6 modules to again improve tree shaking
abilities.
BREAKING CHANGES:
Colors should be passed in the `color` input on components, not added
individually as an attribute on the component.
For example:
```
<ion-tabs primary>
```
Becomes
```
<ion-tabs color=”primary”>
```
Or to bind an expression to color:
```
<ion-navbar [color]="barColor">
...
</ion-navbar>
```
```ts
@Component({
templateUrl: 'build/pages/about/about.html'
})
export class AboutPage {
barColor: string;
constructor(private nav: NavController, platform: Platform) {
this.barColor = platform.is('android') ? 'primary' : 'light';
}
}
```
Reason for this change:
It was difficult to dynamically add colors to components, especially if
the name of the color attribute was unknown in the template.
This change keeps the css flat since we aren’t chaining color
attributes on components and instead we assign a class to the component
which includes the color’s name.
This allows you to easily toggle a component between multiple colors.
Speeds up performance because we are no longer reading through all of
the attributes to grab the color ones.
references #7467closes#7087closes#7401closes#7523
BREAKING CHANGES:
- `<button>` becomes `<button ion-button>`
- `<a button>` becomes `<a ion-button>`
- `<button ion-item>` does not get the `ion-button` attribute
- Buttons inside of `<ion-item-options>` do get the `ion-button`
attribute
- Removed the `category` attribute, this should be passed in
`ion-button` instead.
- Button attributes added for icons in buttons: `icon-only`,
`icon-left`, and `icon-right`
closes#7466
Toolbars can be stacked up vertically in `<ion-header>`,
`<ion-content>`, and `<ion-footer>` elements. However, toolbars also
come with borders on both the top and bottom of the toolbar. To give
developers full control of the design, Ionic also includes the
`no-border-bottom` and `no-border-top` attributes. For example,
sometimes two vertically stacked toolbars may have different background
colors, in this case it might be best to leave a border between them.
However, if they have the same background color, the app may look best
without a border between them. The main point here is, it's entirely up
to the app's design to decide when and when not to show borders between
toolbars, and to do so then each toolbar can individually set
`no-border-bottom` and `no-border-top` attributes.
