We have had errors when generating the docs using jazzy specifically around components giving a fatal error around not finding imports when depending on other components. This is because each component for jazzy is isolated and on its own unless we provide the framework root. This caused our website generator to crash each time and fail to generate a new website.
This should resolve this problem.
QA=
Before the fix when running the website generator we got these errors:
```
/material-components-ios/components/BottomAppBar/src/MDCBottomAppBarView.h:17:9: fatal error: 'MaterialButtons.h' file not found
building site
building search index
^C/Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge/lexer.rb:458:in `load': Interrupt
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge/lexer.rb:458:in `load_lexer'
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge.rb:50:in `block in <top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge.rb:49:in `each'
from /Library/Ruby/Gems/2.3.0/gems/rouge-3.1.1/lib/rouge.rb:49:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/jazzy_markdown.rb:2:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/jazzy_markdown.rb:2:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/doc.rb:7:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/doc.rb:7:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/config.rb:5:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy/config.rb:5:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy.rb:1:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/lib/jazzy.rb:1:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/bin/jazzy:13:in `require'
from /Library/Ruby/Gems/2.3.0/gems/jazzy-0.9.3/bin/jazzy:13:in `<top (required)>'
from /usr/local/bin/jazzy:22:in `load'
from /usr/local/bin/jazzy:22:in `<top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:74:in `load'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:74:in `kernel_load'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli/exec.rb:28:in `run'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli.rb:463:in `exec'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli.rb:27:in `dispatch'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/cli.rb:18:in `start'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/exe/bundle:30:in `block in <top (required)>'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/lib/bundler/friendly_errors.rb:124:in `with_friendly_errors'
from /Library/Ruby/Gems/2.3.0/gems/bundler-2.0.1/exe/bundle:22:in `<top (required)>'
from /usr/local/bin/bundle:22:in `load'
from /usr/local/bin/bundle:22:in `<main>'
/material-components-site-generator/scripts/lib/reporter.js:36
throw e;
^
Error: Command failed: bundle exec jazzy --output "/material-components-site-generator/.stage/ios/catalog/bottomnavigation/api-docs/" --theme "/material-components-site-generator/ios-api-docs-src/theme" --head '/components' --use-safe-filenames
at checkExecSyncError (child_process.js:601:13)
at execSync (child_process.js:641:13)
at JazzyApiGenerator.build (/material-components-site-generator/scripts/lib/jazzy-api-generator.js:34:5)
at PlatformSite.generateApiDocs (/material-components-site-generator/scripts/lib/platform-site.js:212:17)
at platformSites.forEach (/material-components-site-generator/scripts/build:86:14)
at Array.forEach (<anonymous>)
at reporter.step (/material-components-site-generator/scripts/build:85:21)
at Reporter.step (/material-components-site-generator/scripts/lib/reporter.js:32:22)
at Object.<anonymous> (/material-components-site-generator/scripts/build:84:14)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
at Function.Module._load (module.js:497:3)
at Function.Module.runMain (module.js:693:10)
at startup (bootstrap_node.js:191:16)
at bootstrap_node.js:612:3
```
Now we no longer get fatal errors or crash when running the script.
This is the third and last part of the migration of moving the Shape libraries away from the private/ folder. Continuation to PR: #6664 and #6495
Tracking bug, progress and more details can be found here: #6494
This resolves#6494
Because Shapes and ShapeLibrary have been used in production and are an integral part of the shape scheme and theming. Moreover, with to stop the confusion of clients that the library should not be imported as it is under private, we want to migrate the Shape libs to be under components/ instead of components/private.
The migration will be a 7 step migration to not break clients internally.
**We have completed steps 1 to 6, This PR concludes step 7 and the entire migration**
1. move the folders to the new directory.
2. Make the old component's BUILD and Podspec targets depend on the new component (and nothing else).
3. Delete all implementation files from the old component.
4. Replace the contents of the old component's headers with import statements to the new component's header. If the new component has headers that match the old component's, then the new component's headers will need to be named uniquely for a period of time to allow clients to migrate over.
5. Once all clients have migrated from the old component, delete the old component. This is a breaking change.
6. If you had to create temporary header names in the new component, then in a separate release add the new headers that you want the new component to use. Move the content of the old headers into the new headers and replace the old headers with an import of the new headers. Migrate clients to the desired headers.
7. Once all clients have moved off of the old headers, delete the old headers.
This is the first part of the migration of moving the Shape libraries away from the private/ folder.
Tracking bug, progress and more details can be found here: #6494
"Because Shapes and ShapeLibrary have been used in production and are an integral part of the shape scheme and theming. Moreover, with to stop the confusion of clients that the library should not be imported as it is under private, we want to migrate the Shape libs to be under components/ instead of components/private.
The migration will be a 7 step migration to not break clients internally.
1. move the folders to the new directory.
2. Make the old component's BUILD and Podspec targets depend on the new component (and nothing else).
3. Delete all implementation files from the old component.
4. Replace the contents of the old component's headers with import statements to the new component's header. If the new component has headers that match the old component's, then the new component's headers will need to be named uniquely for a period of time to allow clients to migrate over.
5. Once all clients have migrated from the old component, delete the old component. This is a breaking change.
6. If you had to create temporary header names in the new component, then in a separate release add the new headers that you want the new component to use. Move the content of the old headers into the new headers and replace the old headers with an import of the new headers. Migrate clients to the desired headers.
7. Once all clients have moved off of the old headers, delete the old headers.
Passes bazel build and pod build locally.
### Context
As the team pivots to using theming within extensions we continue this work with Chips.
### The problem
We currently do not utilize the theming extension for chips examples
### The fix
* This change updates all the chips examples to use the new chips theming extension.
* Additionally, this updates the shape example to use the new chips theming extension.
### Bug
Closes#6083
This change was automatically generated by running a find replace of the following strings:
```
mdc_unit_test_suite(
mdc_unit_test_suite(
name = "unit_tests",
```
And then running buildifier to enforce style:
find . -name BUILD | xargs ~/buildifier
It appears when the release-candidate was merged back into develop, some code changes were lost/reverted unintentionally.
See for the details here: 026a2005e7
This change brings all the necessary changes back into develop. Specifically around the cards theming extension and the updated Card theming examples.
This issue appears to stem from the fact that these 2 PRs landed in develop after the release-candidate was branched:
#6048#6049
This reverts commit fdaf872c605cab44a4579cb8b7f0ea168c445318. The
container scheme import is missing in a Swift example.
```
material_components_ios/components/Cards/examples/EditReorderCollectionViewController.swift:38:24 use of undeclared type 'MDCContainerScheming'
var containerScheme: MDCContainerScheming {
^~~~~~~~~~~~~~~~~~~~
```
Reopens#6030
This is an automated change generated by running the following command:
find . -name BUILD | xargs buildifier
buildifier can be installed from https://github.com/bazelbuild/buildtools
This change formats all of our BUILD files with the buildifier formatter in preparation for us having a BUILD format linter as part of our presubmits and so that we can cleanly run buildozer commands against the codebase.
Some of our examples and component code was depending on other components by
using relative path imports. Instead, they should be relying on the build
system to expose headers and importing those from the include paths.
* [Dialogs, Shape] Fix cross-component imports.
Some of our examples and component code was depending on other components by
using relative path imports. Instead, they should be relying on the build
system to expose headers and importing those from the include paths.
* Fix additional Dialogs import.
Also some formatting improvements.
* Revert merge conflict in ActionSheetTest.swift
* Fixing import in Alert Typography themer.
{MDC iOS} No longer using `-init` for Color Scheme.
Based on the discussions in go/mdc-ios-theming, we should not use the `-init` default initializer. Instead, we should use an explicit set of defaults.
Search regex: '\[\[MDCSemanticColorScheme alloc\] init\]'
Replacing all non-integral, single-precision floating point literals with double-precision values explicitly cast to CGFloat. For example, `0.1f` should become `(CGFloat)0.1`.
Regex used:
```
([0-9]*\.)([0-9]*?)([1-9]+)([0-9]*?)[fF]
```
PiperOrigin-RevId: 220683126
### Context
After releasing the Shape Theming code, this provides initial documentation for how to use shape theming, and its API.
### The problem
We lack documentation on what is Shape Theming, and how do you use it.
### The fix
An Initial doc outlining shape theming.
### Bug
Closes#4605Closes#4606
This closes#5146 .
This example allows our users to set each one of the Scheme's categories, Small Surface, Medium Surface, and Large Surface. It also allows the user to toggle the baseline overrides for the components that override the scheme like FAB and Chips. You can see how the scheme changes updates the different components.
See below gif:
**<><>This is a breaking change<><>**
There are slight terminology updates to the current Shape Scheme.
First, we are staying with the Cut notion for cut corners rather than Angled. This is on par with our current naming of the CutCornerTreatment.
Secondly, we are moving from the term S/M/L Surface to S/M/L Component for the scheme categories.
This will allow us to set percentage support for a corner treatment as a follow up PR. Reason being is that the MDCCornerTreatment is part of the shape of the component itself, and hence has control to set the value of the corner when it is right in the lifecycle and the frame has been set. If we keep the percentage value setting in the Shape Themer, then the themer could be applied too early in the lifecycle and thus take a percentage off a 0 value (frame height).
Overall this simplifies the API and causes less duplication.
The other approach would be to *also* add percentage support to MDCCornerTreatment and leave MDCShapeCorner as is, but that would just make it too cumbersome and redundant.
This PR changes the recent addition of convenience initializers of MDCCornerTreatments to become a certain instance subclass to use concrete types rather than a generic NSNumber with parsing. This resolves#5063
This PR implements the initial Shape Scheme that is essential for allowing shape theming for components (*this doesn't include any themers and that will be included as a separate PR once this is approved*). More information can be seen in go/mdc-ios-shape-theming and go/material-shapes-eng
This closes#4609#4612#4613
