Improve the experience and performance of the staging server in Venia and other PWAs, as well as slimming down the install time and dependency size of PWA Studio itself.
Is your feature request related to a problem? Please describe.
We don't have a coherent place for staging server scripts. NodeJS is one of our core supported technologies; we should have a more complete story for staging and running production servers in Node.
We haven't done this because we don't want to make any core features require NodeJS serving the PWA. That's the reason for UPWARD in the first place. But we can scope a staging server carefully so it doesn't insert any features the PWA requires. UPWARD is only part of this solution: the upward-js library is supposed to be general-purpose, so it's not the appropriate place to put a staging server specifically designed for PWA Studio. So we need a staging server command that uses upward-js internally. That way, we can take some of the staging server stuff scattered throughout the codebase and organize it in one place.
Describe the solution you'd like
A new built-in staging server
A new Buildpack CLI command, buildpack serve.
It probably shouldn't take many arguments; like the rest of PWA Studio, it should be driven by environment variables. Its default behavior should simply be to serve the current directory, though it could take the directory as an argument.
Most of its functionality would be taken from venia-concept/server.js; it should load the environment, use a custom host where available, run an Express server, attach compression (see "Additional context" section below), image optimization, and any other middleware to it, and bind the server. (It should always run in the foreground, because it's 2020 and we use virtualization instead of job control.)
Reorganize other packages.
Use @magento/pwa-buildpack in dependencies of venia-concept instead of devDependencies. Remove @magento/upward-js from venia-concept dependencies.
Remove the venia-concept/server.js script. Replace the start script in venia-concept with buildpack serve.
Remove the bestPractices method from upward-js. That never belonged there! All it does is add a compression middleware.
Remove the shrink-ray-current dependency from upward-js (see "Additional context" section below).
Remove the upwardJs.bestPractices() call from UpwardDevServerPlugin. The dev server shouldn't be using compression middleware anyway. (It should still use image optimization middleware, though.)
Remove the optional dependencies iltorb and node-zopfli-es everywhere from every package in the project. Phew!
Describe alternatives you've considered
A separate package like @magento/serve-pwa would be nice and light, but it depends on buildpack to load its environment, and buildpack would depend on it for its serve command. That might be workable if we split buildpack up into separate projects down the line, but that's not soon.
Additional context
Why now
This came up because in https://github.com/magento/pwa-studio/pull/2315 I noticed that the contributor had pushed an update to iltorb. It was good of him to do that, but we don't actually need iltorb anymore.
On removing shrink-ray-current
We should get rid of shrink-ray-current. It requires large native extensions iltorb and node-zopfli-es (those are what take so long to build when installing PWA Studio). And we don't need either of those! Node >=10 supports Brotli natively, so it doesn't need iltorb; and node-zopfli-es is unused in our project, because Zopfli compression should be done at build time by Webpack in the first place.
The only things about shrink-ray that we're using are its API and its ETag functionality. I've created a new package called https://github.com/magento-research/compression-middleware-modern which can replace shrink-ray-current when it's done. That package uses no binary deps.
Please let us know what packages this feature is in regards to:
Improve the experience and performance of the staging server in Venia and other PWAs, as well as slimming down the install time and dependency size of PWA Studio itself.
Is your feature request related to a problem? Please describe. We don't have a coherent place for staging server scripts. NodeJS is one of our core supported technologies; we should have a more complete story for staging and running production servers in Node.
We haven't done this because we don't want to make any core features require NodeJS serving the PWA. That's the reason for UPWARD in the first place. But we can scope a staging server carefully so it doesn't insert any features the PWA requires. UPWARD is only part of this solution: the
upward-js
library is supposed to be general-purpose, so it's not the appropriate place to put a staging server specifically designed for PWA Studio. So we need a staging server command that usesupward-js
internally. That way, we can take some of the staging server stuff scattered throughout the codebase and organize it in one place.Describe the solution you'd like
A new built-in staging server
buildpack serve
.venia-concept/server.js
; it should load the environment, use a custom host where available, run an Express server, attach compression (see "Additional context" section below), image optimization, and any other middleware to it, and bind the server. (It should always run in the foreground, because it's 2020 and we use virtualization instead of job control.)Reorganize other packages.
@magento/pwa-buildpack
independencies
ofvenia-concept
instead ofdevDependencies
. Remove@magento/upward-js
fromvenia-concept
dependencies.venia-concept/server.js
script. Replace thestart
script invenia-concept
withbuildpack serve
.bestPractices
method fromupward-js
. That never belonged there! All it does is add a compression middleware.shrink-ray-current
dependency fromupward-js
(see "Additional context" section below).upwardJs.bestPractices()
call fromUpwardDevServerPlugin
. The dev server shouldn't be using compression middleware anyway. (It should still use image optimization middleware, though.)iltorb
andnode-zopfli-es
everywhere from every package in the project. Phew!Describe alternatives you've considered A separate package like
@magento/serve-pwa
would be nice and light, but it depends onbuildpack
to load its environment, andbuildpack
would depend on it for itsserve
command. That might be workable if we splitbuildpack
up into separate projects down the line, but that's not soon.Additional context
Why now
This came up because in https://github.com/magento/pwa-studio/pull/2315 I noticed that the contributor had pushed an update to
iltorb
. It was good of him to do that, but we don't actually need iltorb anymore.On removing
shrink-ray-current
We should get rid of
shrink-ray-current
. It requires large native extensionsiltorb
andnode-zopfli-es
(those are what take so long to build when installing PWA Studio). And we don't need either of those! Node >=10 supports Brotli natively, so it doesn't neediltorb
; andnode-zopfli-es
is unused in our project, because Zopfli compression should be done at build time by Webpack in the first place.The only things about
shrink-ray
that we're using are its API and its ETag functionality. I've created a new package called https://github.com/magento-research/compression-middleware-modern which can replaceshrink-ray-current
when it's done. That package uses no binary deps.Please let us know what packages this feature is in regards to:
venia-concept
venia-ui
pwa-buildpack
peregrine
pwa-devdocs
upward-js
upward-spec
create-pwa