-
Notifications
You must be signed in to change notification settings - Fork 800
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
Lazy Images: Use calypso-build to build #17571
Conversation
Scheduled Jetpack release: December 1, 2020. Thank you for the great PR description! When this PR is ready for review, please apply the |
3c75041
to
b9c3a4e
Compare
Planning to pick this up tomorrow! |
39d319e
to
3fdb592
Compare
Should be ready for review. |
package.json
Outdated
@@ -19,13 +19,13 @@ | |||
"build-client": "gulp", | |||
"build-concurrently": "yarn install-if-deps-outdated && yarn clean && yarn concurrently 'yarn build-client' 'yarn build-php' 'yarn build-extensions' 'yarn build-search' 'yarn build-packages'", | |||
"build-extensions": "webpack --config ./webpack.config.extensions.js", | |||
"build-packages": "webpack --config ./webpack.config.packages.js", | |||
"build-packages": "cd packages/lazy-images/ && npm run build && cd ../../", |
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.
Any reason we use npm
instead of yarn
?
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.
Also the cd ../../
shouldn't be necessary, yarn does its thing in a subshell.
If that's future-proofing for potentially having to build more packages in the future, it might be best to future-proof a little further and put the commands in a build script in bin/
.
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.
Any reason we use
npm
instead ofyarn
?
Oversight on my part, apologies. I'll change to npm
👍 Thanks for spotting 👍
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.
Also the
cd ../../
shouldn't be necessary, yarn does its thing in a subshell.
Good point, I'll remove it 👍
If that's future-proofing for potentially having to build more packages in the future, it might be best to future-proof a little further and put the commands in a build script in
bin/
.
I did it indeed for future-proofing! If we end up building more packages like this, I'd prefer using lerna
, much like we do in Calypso, since it allows running the same command across a number of packages. (That would also allow us dropping the cd packages/lazy-images/
here.) See e.g. https://github.com/Automattic/wp-calypso/blob/8b3ef578098c061eb6838c516761822908e911cb/package.json#L95, which basically runs the prepare
script across all packages listed in lerna.json
.
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.
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.
Aaand f9c48b8 to use yarn
instead of npm run
.
package.json
Outdated
@@ -19,13 +19,13 @@ | |||
"build-client": "gulp", | |||
"build-concurrently": "yarn install-if-deps-outdated && yarn clean && yarn concurrently 'yarn build-client' 'yarn build-php' 'yarn build-extensions' 'yarn build-search' 'yarn build-packages'", | |||
"build-extensions": "webpack --config ./webpack.config.extensions.js", | |||
"build-packages": "webpack --config ./webpack.config.packages.js", | |||
"build-packages": "cd packages/lazy-images/ && npm run build && cd ../../", |
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.
Also the cd ../../
shouldn't be necessary, yarn does its thing in a subshell.
If that's future-proofing for potentially having to build more packages in the future, it might be best to future-proof a little further and put the commands in a build script in bin/
.
packages/lazy-images/package.json
Outdated
}, | ||
"homepage": "https://github.com/Automattic/jetpack", | ||
"scripts": { | ||
"clean": "npx rimraf dist", |
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 does this do that "rm -rf dist"
doesn't?
Other than download and run code from the Internet, of course.
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 cross-platform, so it should also work on Windows -- at least that's why we're using it in Calypso, which is where I copied it from 🙂
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'm not sure how much of Jetpack's stuff is intended to be run on Windows, versus gets run inside a Linux docker container anyway. I do see that the "clean" scripts in Jetpack's package.json all just use rm -rf
.
If you are going to use a node thing, IMO it would be better to just declare it as a dependency instead of having npx download an arbitrary version at runtime.
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.
Happy to use rm -rf
, if that's what JP does for everything else 👍
packages/lazy-images/package.json
Outdated
"scripts": { | ||
"clean": "npx rimraf dist", | ||
"prebuild": "yarn run clean", | ||
"build": "calypso-build lazy-images='./src/js/lazy-images.js' intersectionobserver-polyfill='./src/js/intersectionobserver-polyfill.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.
Should the dependency on @automattic/calypso-build be declared below, so this works standalone in addition to when being called from ../../package.json?
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, makes sense! I'll add it as a devDependency.
Just noticed that |
Thanks @brbrr and @anomiex for reviewing! I think I've addressed all feedback. One remaining question:
|
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.
In comments on #17562, it was brought up that we might need to include the built
js
files in GH in order for composer to be able to export this package. This would mean adding thedist/
directory. Should we do that? Or can composer include a build step for JS?
Composer itself probably can't include a build step for JS. It seems to use whatever you get from e.g. https://github.com/Automattic/jetpack-lazy-images/archive/v1.2.0.zip. Can you have a build step for those Github zip downloads? Or can whatever mirrors the code from this monorepo into https://github.com/Automattic/jetpack-lazy-images/ run your build step? I don't know.
Or can we do release branches that have the files checked in even if they're not checked into master, and live with the composer package not working if someone tries to use "dev-master" or anything else that's not one of those release branches?
Note that you're also depending on node_modules/intersection-observer/intersection-observer.js, so that would also have to be checked into the repo if you can't figure out how to do a build step.
packages/lazy-images/.gitignore
Outdated
@@ -1,3 +1,5 @@ | |||
dist | |||
node_modules | |||
vendor | |||
wordpress | |||
composer.lock |
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.
Looks like yarn creates a "yarn.lock" file that should probably also be ignored.
Ah, I wasn't even aware of that repo, thanks for bringing that up!
We can have something like that, yeah: A GitHub action that's triggered by adding a new tag and then runs the build step and creates a release with the resulting zip attached as an asset. (Here's an example of what that looks like: WordPress/gutenberg#19626 and https://github.com/ockham/gutenberg/releases/tag/untagged-91af46b87ff343e447c9) However, the resulting file will have a somewhat different URL. (The one your reference is GitHub's automatically provided zip of the archive contents, whereas we'll have to attach our own asset to the release.) Is it possible to change that URL wherever it's used to fetch that zip?
I think the GH action based approach is cleaner -- it runs the build step when it should be conceptually run, at the time of building a release.
🤔 Possibly, but overall, that seems a bit messier...
Good point, thanks for bringing that up. Ideally, I'd like to avoid checking a |
I don't think that's an option, since we use |
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 tests well for me. I wonder if it may be worth marking this more than a patch change since we're moving built files around. But absolutely not a blocker, up to you!
The question there is whether the paths or URLs of those JS files would be considered part of the "API" of the package, or just an internal implementation detail. Let's err on the safe side.
The question there is whether the paths or URLs of those JS files would be considered part of the "API" of the package, or just an internal implementation detail. Let's err on the safe side. |
Caution: This PR has changes that must be merged to WordPress.com |
Great news! One last step: head over to your WordPress.com diff, D62642-code, and commit it. Thank you! |
r227091-wpcom |
Fixes #17562 -- or rather, most of it:
One item from #17562 isn't addressed by this PR:
I haven't yet found a really good way to do that, as we also need to build it, and include it as an external. We can address that in a subsequent iteration however.
Changes proposed in this Pull Request:
Use
calypso-build
to build the lazy-images package.Jetpack product discussion
N/A
Does this pull request change what data or activity we track or use?
No
Testing instructions:
yarn build-production-packages
, and verify that it passes (it includes ES5 validation!).(I've tested a post with an image and the Lazy Images setting switched on and it seemed to work fine, but I'm not familiar enough with lazy images to be 100% certain that it's still working as before.)
Proposed changelog entry for your changes:
Use
calypso-build
to build the lazy-images package.Note
In comments on #17562, it was brought up that we might need to include the built
js
files in GH in order for composer to be able to export this package. This would mean adding thedist/
directory. Should we do that? Or can composer include a build step for JS?