root.phtml includes hardcoded reference to pub/static about pwa-studio

[PWAStudioBot]

From @fooman on May 12, 2018 10:43

Using getViewFileUrl() does not work unfortunately. There is a disconnect between what is the URL of the M2 instance and what is provided by node, currently hardcoded to https://magento-venia.local.pwadev:8000. In my trials I have for now resorted to using <script src="https://magento-venia.local.pwadev:8000/static/frontend/Magento/venia/en_US/client.js"></script>.

[PWAStudioBot]

From @erfanimani on May 26, 2018 1:39

I was going to make a pull request with exactly the same fix you provided, and then stumbled upon this ticket. I still think using getViewFileUrl is much better than it is currently (because pretty much everyone will run into this issue). The only reason to link to node instead of the server Magento is running off, is the hot-reloading stuff right?

Additionally, running:

./node_modules/webpack/bin/webpack.js \
    --progress \
    --color \
    --env.phase development && find . | grep client\.js

for me outputs

./web/js/client.js
./web/js/client.js.map

Meaning that instead of referencing client.js, it should be referencing js/client.js, or am I missing something?

edit: to be clear, <script src="<?php echo $this->getViewFileUrl('js/client.js') ?>"></script> fixed the client.js 404 for me.

[PWAStudioBot]

From @erfanimani on May 26, 2018 10:39

Just had a chat in CommEng, and disregard my previous comment. It seems you need to run Venia from the nodeJS server, which then proxies some requests through to the Magento backend, not the other way around (which I think is what you're doing @fooman?). Because client.js is provided by the proxy, it doesn't matter what the URL is. Whether you're running from pub or not shouldn't matter. Correct me if wrong..

[PWAStudioBot]

From @DrewML on June 2, 2018 8:1

In 100% agreement that the value in root.phtml shouldn't be hard-coded.

One thing I think we might want to do, though, is not use the pub/static path in development. If the asset is always coming from the webpack-dev-server, but links to pub/static, every new dev (who is familiar with m2) on this project is going to be surprised when they don't see that same file on disk.

It might make more sense if, during development, that path changes to something like /webpack-server/client.js. What do you think @fooman @erfanimani @jissereitsma?

[PWAStudioBot]

From @erfanimani on June 2, 2018 10:8

We we have to run the dev server? Or can we just run

./node_modules/webpack/bin/webpack.js \
    --progress \
    --color \
    --env.phase development

and achieve the same outcome? Without the hot reloading stuff.

[PWAStudioBot]

From @DrewML on June 2, 2018 10:24

@erfanimani at the moment (for the happy path) yes. There hasn't been any focus so far on hooking into the normal static content deploy step. In theory you could setup a script to copy things down and they should work, but may require some more tweaking of the current webpack config.

If you're interesting in working on it, or talking through it more, could be fun to get on a call and discuss.

[PWAStudioBot]

From @erfanimani on June 4, 2018 9:11

Thanks @DrewML. The reason I asked is because if we can run webpack directly for compilation as an alternative method to the dev server, then it would make sense to use getViewFileUrl (and somehow make the dev server work with the version string).

In that case, then for new developers there would need to be an explanation; if the file isn't on disk (or it has been changed), they need to run webpack compilation (which I assume is what happens on prod?), or (preferred) run their Magento install through the proxy which would take care of the missing file.

I'm not sure if I'm making sense (I also don't fully understand what else the dev proxy does).. I'll ping you on #pwa commeng channel :)

[mhhansen]

quick update
While trying to solve this one, found that the path to the precache-manifest file, inside service-worker (and all the referenced paths inside the precache file) are wrongly referenced.

Solution provided by fooman, using the getViewFileUrl works OK for the client.js, while running a prod build of venia (not in dev mode).

Didn't find a way to indicate which path the precache-manifest should use to reference the assets and how to tell sw.js file to use the themePaths.output (web/js), instead of the themePaths.assets (which is: web/).

So currently I'm ending up with a webpackJsonp is not defined (because vendor.js file is not loaded), since sw.js file points to web/precache-manifest.xxxx.js instead of web/js/precache-manifest.xxxx.js

folder structure

service worker precache url

precache-manifest urls

will be reading some docs of workbox lib, in case I'm missing something
thanks!

[mhhansen]

More on the asset path problem in the production build version:
Since Magento frontend exposes /static/versionXXXXX/ for assets urls, it will impact in other aspects of the app.

As far as I saw:

1. How peregrine's resolveUnknownRoute class reads the roots-manifest.json (it's using webpackPublicPath which points to /pub/static/...)
2. How precache-manifest-xxxx.js builds it's urls (all pointing to /pub/static/...)
3. How the ending SW tries to call files within importScript() (also to /pub/static/...)

So, I'll be creating a PR to resolve this hardcoded reference in the root.phtml by implementing getViewFileUrl() which seems to be enough to get client.js file, and then ask in #pwa channel to fire up another issue to address related aspects described above.

sounds good ?

EDIT also mention that despite client.js will load OK, vendor.js is required by client.js but never included.

[mhhansen]

also mention that despite client.js will load OK, vendor.js is required by client.js but never included.

this will be solved when #219 is merged, since it's including vendor.js file based on production mode

[zetlen]

This will remain hardcoded in the 1.x.x release stream.