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
[Doc] buildpack ref docs #2508
[Doc] buildpack ref docs #2508
Conversation
|
Performance Test Results The following fails have been reported by WebpageTest. These numbers indicates a possible performance issue with the PR which requires further manual testing to validate. https://pr-2508.pwa-venia.com : LH Performance Expected 0.85 Actual 0.34, LH Accessibility Expected 1 Actual 0.97, LH Best Practices Expected 1 Actual 0.92, WPT Cache Expected 90 Actual 39.333333333333 |
…jimothy/buildpack-ref-docs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Partial review for @jcalcaben because I'm taking so long with this process. There's enough here to start a conversation--I'll continue to review this and the other two after submitting.
* for dependencies with Targets to interact with each other. | ||
* | ||
* Manages dependency participation in project builds and tasks. | ||
* It connects dependencies with Targets and lets them interact with each other. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might want to add something like executes their declare and intercept files so they can interact with each other
.
* Respond to a request from a [TargetProvider]{@link https://pwastudio.io/pwa-buildpack/reference/buildbus/targetprovider/} | ||
* to retrieve a different(external) TargetProvider. | ||
* | ||
* When using a TargetProvider disconnected from a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I sort of regret this aside, because I can't think of a single reason you'd use a TargetProvider disconnected from a BuildBus. Maybe this should just say "This callback pattern helps to loosely couple TargetProviders so they are more testable."
* Collects requests to intercept and modify individual files from this | ||
* dependency. Only files from the currently requesting dependency may | ||
* dependency. | ||
* | ||
* Only files from the currently requesting dependency may | ||
* be transformed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I wrote is no longer accurate. We added an exception for interceptor files in the project itself (e.g. venia-concept) to be able to transform ANY file from ANY dependency. It's only the dependencies (e.g. venia-ui) that are prevented from modifying files from other dependencies (e.g. peregrine).
We did this because a custom interceptor file for the project should be able to do whatever it wants, since it's presumably maintained by the project author who is also in charge of importing dependencies.
Can you help me to put that here?
@@ -196,3 +179,65 @@ module.exports = targets => { | |||
|
|||
targets.declare(builtins); | |||
}; | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohhh, this makes sense. Thanks for this reorg.
Co-authored-by: James Zetlen <jzetlen@adobe.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finishing up the first round. Thanks for your patience.
* Since the storefront developer is in charge of important dependencies, | ||
* the interceptor files in the storefront project itself should be able to | ||
* transform ANY file from ANY dependency. | ||
* However, interceptor files in the storefront dependencies are prevented |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
{ | ||
target: 'pwa-buildpack/lib/BuildBus/declare-base.js', | ||
type: 'function' | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this belong here? The declare-base.js
file is what declares Buildpack targets, so we wrote the doc blocks in that file. But the targets themselves are in a different category of thing, which should be documented in a separate "Targets" section, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't add another level of nesting to the navigation, so they will all need to go under "Extensibility"
- label: BuildBus | ||
url: /pwa-buildpack/reference/buildbus/ | ||
entries: | ||
- label: Extensibility Targets | ||
url: /pwa-buildpack/reference/buildbus/targets/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that I called the directory BuildBus
in source code, but I think in documentation, the top-level item should be called "Extensibility" and there should be an additional entry below, called "BuildBus".
- label: ModuleTransformConfig | ||
url: /pwa-buildpack/reference/moduletransformconfig/ | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This belongs under Extensibility
Co-authored-by: James Zetlen <jzetlen@adobe.com>
* docs: elaborate on envVarDefinitions API * Apply suggestions from code review Co-authored-by: James Zetlen <jzetlen@adobe.com> * Update pwa-devdocs/src/pwa-buildpack/reference/environment-variables/index.md Co-authored-by: James Calcaben <jcalcaben@users.noreply.github.com> * Update pwa-devdocs/src/pwa-buildpack/reference/environment-variables/index.md Co-authored-by: James Calcaben <jcalcaben@users.noreply.github.com> * docs: elaborate on envVarDefinitions API Co-authored-by: James Calcaben <jcalcaben@users.noreply.github.com>
* bluh * docs: reorg buildpack ref path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Verification steps look good. |
Description
This PR updates the JSDocs in the targets in the Buildpack package.
It also creates a file in devdocs that pulls this information into a reference-style topic.
Related Issue
Closes PWA-703
Acceptance
@zetlen
Verification Stakeholders
@zetlen
Specification
Verification Steps
Navigate to the pwa devdocs directory:
cd pwa-devdocs
Start the HTML preview server:
yarn develop
Verify files are auto-generated:
src/_includes/auto-generated/pwa-buildpack/lib/WebpackTools/ModuleTransformConfig.md
src/_includes/auto-generated/pwa-buildpack/lib/BuildBus/declare-base.md
src/_includes/auto-generated/pwa-buildpack/lib/BuildBus/BuildBus.md
src/_includes/auto-generated/pwa-buildpack/lib/BuildBus/TargetProvider.md
src/_includes/auto-generated/pwa-buildpack/lib/BuildBus/Target.md
src/_includes/auto-generated/pwa-buildpack/lib/Utilities/getEnvVarDefinitions.js
On the devdocs preview site, in the top navigation, click on PWA Buildpack under the Reference API item.
Verify new navigation layout
Verify all the links under the Extension points, Extension framework, Developer utilities, Webpack tools, and Environment configuration sections work.
Screenshots / Screen Captures (if appropriate)
Checklist