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
[PWA-355]: Add richer extension points and documentation #2298
Conversation
|
fd0d1f7
to
3022c67
Compare
a256539
to
9ad094a
Compare
ce34273
to
a64d3a2
Compare
|
||
## exception: commit node_modules folders in test fixtures | ||
!**/__fixtures__/*/node_modules |
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.
Testing the test helpers meant adding fixtures with node_modules directories.
'\\.svg$': 'identity-obj-proxy' | ||
'\\.svg$': 'identity-obj-proxy', | ||
'@magento/venia-drivers': | ||
'<rootDir>/packages/venia-ui/lib/drivers/index.js' |
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.
Many of these small changes were for Jest 25 (see below)
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.
Actually Jest 26 now
…zetlen/talon-targets
…zetlen/talon-targets
…zetlen/talon-targets
Changes discussed. I think Zetlen has created necessary followups.
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-2298.pwa-venia.com : LH Performance Expected 0.85 Actual 0.58, LH Best Practices Expected 1 Actual 0.92 |
…-studio into zetlen/talon-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.
@zetlen I like this approach, and it's nice to see this PR using the new API it introduces to implement some of the things we're already comfortable with, such as routes. It's also great to see all the tests accompanying all the additions and modifications here.
This is an enormous amount of code to add at once, though; it's difficult to review all of this code carefully, and doing so would delay it by a fair bit longer. So I will note that while it's a huge step forward, it is also adding a fair bit of new risk—I can validate the approach and trust in the tests & QA, but ultimately I just have to hope it works.
Let's keep a close eye on how the first few integrations go.
afterEach(() => { | ||
window.location = oldWindowLocation; | ||
}); | ||
|
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 is...gross. If I were writing the unit test for this effect, I would sooner give up than do this kind of mocking. Is there something earlier in the chain we can mock, if window.location
is going to be this bad?
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 don't like it, but it's the only approach I've seen in extensive research on the subject. It's not that unusual, though. It belongs to a whole class of problems mocking globals in JSDOM.
|
||
test('enables third parties to wrap talons', async () => { | ||
// sorry, buildModuleWith is slow. TODO: make it take less than a minute? | ||
jest.setTimeout(60000); |
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 agree, this is not great and could be improved. At the same time, I'm not sure how much we want to optimize for actual developers blindly running all tests. I think running all tests at once should be avoided, generally, when dealing with a monorepo. But it will happen sometimes, so it probably shouldn't take forever.
As Zetlen said, jest --watch
is the recommended approach. I go a step further and input the exact tests I want to run and the exact directories from which I want to collect coverage, which is easy to do with yarn test
or yarn jest
.
if (this._hasRun[phase]) { | ||
return; | ||
} | ||
this._hasRun[phase] = true; |
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.
Minor suggestion: cases like this are good for a Set
, since you're just adding arbitrary strings and then checking for their presence.
this._hasRun = new Set()
if (this._hasRun.has(phase) return
this._hasRun.add(phase)
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.
It's true, though I think it's a micro-optimization, since the number of phases is unlikely to get much larger.
/** @public */ | ||
static clear() { | ||
throw new Error( | ||
'MockedBuildBus.clear() not supported. More details at https://twitter.com/JamesZetlen/status/1244683087839137792' |
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.
Yeah, the only tweet I've ever linked in a code comment has since been deleted.
} | ||
for (const filename of compilation.fileDependencies) { | ||
if (filename.endsWith('.graphql')) { | ||
queryFilePaths.push(filename); |
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 a coincidence! #2420
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.
lol
)}` | ||
); | ||
} | ||
// if we got here, both have been seen, so this is an exact duplicate; |
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.
When we're discussing routes here, we're discussing paths to a module ("Babel routes"), correct?
Not URL patterns?
@@ -0,0 +1,3 @@ | |||
export const Component = ({ html }) => `I declare ${html}`; |
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 declare bankruptcy!
…zetlen/talon-targets
@zetlen
|
…-studio into zetlen/talon-targets
Description
Add features to the extensibility framework to support rich integration with Peregrine talons. This enables extensions that can deeply integrate analytics and segmentation code.
Features
wrapEsmModules
target to a lower-level, more versatiletransformModules
targetsource
and with transformModulewrap-esm-loader
.babel
allows for AST manipulation.transformModules
can only intercept their own files.talons
target for wrapping talon functionsApp.useApp
andProductFullDetail.useProductFullDetail
implemented so farroutes
target for adding custom routesChanges
MagentoResolver
to support some common development scenariosconfigureWebpack
into smaller modules for creating different parts of Webpack configDocs
Related Issue
Closes #PWA-355.
Acceptance
Verification Stakeholders
@magento/pwa-studio-team
Verification Steps
There is a step-by-step tutorial in the getting started guide! This can serve as a verification repro.
Quick Start
Proceed through the steps and verify that you can create a new custom route from within the repository.
Additional verification: create a separate package to implement the same functionality as a module. See Extension Development
Checklist