Please ensure that your service worker file contains the following:/(const precacheManifest =)\[\](;)/ - node.js

I am quite new to react React workbox. I am trying to make my Electron react App have the ability to cache all images and data to be made available while it is offline.
This is exactly what I am trying to accomplish as in this youtube video. from 14:00 to 21:00 minutes: Building PWAs with React and Workbox, /watch?v=Ok2r1M1jM_M
But this command is giving
"start-sw":"workbox injectManifest workbox-config.js && workbox copylibraries build/ && http-server build/ -c 0"
This error:
C:\Users\rajesh.ram\Desktop\Day\K\demok\client>npm run start-sw
> client#0.1.0 start-sw C:\Users\rajesh.ram\Desktop\Day\K\demok\client
> workbox injectManifest workbox-config.js && workbox copylibraries build/ && http-server build/ -c 0
Using configuration from C:\Users\rajesh.ram\Desktop\Day\K\demok\client\workbox-config.js.
Service worker generation failed:
Unable to find a place to inject the manifest. Please ensure that your service worker file contains the followin
g:/(const precacheManifest =)\[\](;)/
Please help me fix this or suggest alternative packages/repositories/videos to make it possible.

In newer workbox versions including 5.1.3 current at time of this post , the parameter which specifies the injectionPoint for the precacheManifest has changed from regex to string. The name of the parameter has also changed and as far as I can tell this is not backwards compatible...meaning it doesn't work to use the regex anymore.
module.exports = {
"globDirectory": "build/",
"globPatterns": [
"**/*.{json,ico,html,png,js,txt,css,svg}"
],
"swDest": "build/sw.js",
"swSrc": "src/sw.js",
"injectionPoint": "injectionPoint"
}
Changing that parameter as per above worked for me following the rest of the video.
Then several other updates affected how sw.js is written also...
importScripts("workbox-v5.1.3/workbox-sw.js");
workbox.setConfig({ modulePathPrefix: "workbox-v5.1.3/" });
const precacheManifest = [injectionPoint];
workbox.precaching.precacheAndRoute(precacheManifest);
You have to remove the .supressWarnings() command. It has been removed. A good video...needs some updates.
Link to the presentation github which needs an update so...
https://github.com/mikegeyser/building-pwas-with-react
Link to the manual: https://developers.google.com/web/tools/workbox/reference-docs/latest/module-workbox-build
#MegPhillips91

By changing the parameter of precacheAndRoute as below it worked for me
workbox.precaching.precacheAndRoute(self.__WB_MANIFEST);

If you're following the video strictly, make sure that the custom sw.js file that you create in the src folder is exactly:
importScripts("workbox-v4.3.1/workbox-sw.js");
workbox.setConfig({ modulePathPrefix: "workbox-v4.3.1/" });
const precacheManifest = [];
workbox.precaching.suppressWarnings();
workbox.precaching.precacheAndRoute(preCacheManifest);
and workbox-config.js
module.exports = {
globDirectory: "build/",
globPatterns: ["**/*.{json,ico,html,png,js,txt,css}"],
swDest: "build/sw.js",
swSrc: "src/sw.js",
injectionPointRegexp: /(const precacheManifest = )\[\](;)/
};
make sure the workbox version matches the version you have in the video he uses 3.6.3 but now its 4.3.1.....hope this helps.

Related

Gatsby Source Drupal not fetching data when trying to deploy to netlify/heroku

I have a site running Gatsby and Gatsby-Source-Drupal7, it is a plugin that uses Graphql to make an axios get request to https://stagingsupply.htm-mbs.com/restws_resource.json and uses the json data to query. I am able to run it just fine on my computer by going to localhost:8000 and it creates over 200k nodes, but when I try to deploy on any cloud service provider like Gatsby Cloud or Netlify it doesn't fetch any nodes or data at all from the site.
Warning from console
Starting to fetch data from Drupal
warn The gatsby-source-drupal7 plugin has generated no Gatsby nodes. Do you need
it?
Code
code from gatsby config
module.exports = {
siteMetadata: {
title: `new`,
siteUrl: `https://www.yourdomain.tld`,
},
plugins: [
{
resolve: `gatsby-source-drupal7`,
options: {
baseUrl: `https://stagingsupply.htm-mbs.com/`,
apiBase: `restws_resource.json`, // optional, defaults to `restws_resource.json`
},
},
]
}
gatsby-config.js from node_modules/gatsby-source-drupal7
const createNode = actions.createNode; // Default apiBase to `jsonapi`
apiBase = apiBase || `restws_resource.json`; // Fetch articles.
// console.time(`fetch Drupal data`)
console.log(`Starting to fetch data from Drupal`);
const data = yield axios.get(`${baseUrl}/${apiBase}`, {
auth: basicAuth
});
const allData = yield Promise.all(_.map(data.data.list,
Link to repo that works on local computer https://github.com/nicholastorr/gatsby-d7
any and all help will be appreciated
As you pointed out, you've played around with the Node versions using NODE_ENV and engines workarounds. My guess also relies on a mismatching Node version between environments but as Netlify docs suggests, there are only two ways of customizing Node versions to manage dependencies.
Set a NODE_VERSION environment variable.
Add a .node-version or .nvmrc file to the site’s base directory in your repository. This will also tell any other developer using the
repository which version of Node.js it depends on.
Without seeing your Netlify build command (to see the NODE_VERSION) there's no .node-version nor .nvmrc in your repository. I'd try creating it at the root of the project with the v14.17.1 in it and trying a fresh install.
In addition, double-check other server-related conflicts like IP-blocking, etc.
Error was nothing Gatsby or Node related, my site was block the IP of the server :>

React boilerplate - changing API url at runtime

I'm using react-boilerplate as the base for my project.
I'm currently defining my API url in webpack.base.babel.js like so:
new webpack.DefinePlugin({
'process.env': {
NODE_ENV: JSON.stringify(process.env.NODE_ENV),
PIZZA_API_URL: JSON.stringify('https://some-ip:8081')
},
}),
However, this is only picked up at build time.
In create-react-app, you can use REACT_APP_PIZZA_URL. Anything that starts with REACT_APP* can be set at the start of runtime.
So I can do:
docker run -e "REACT_APP_DB_HOST=HELLOWORLD" -d -p3000:3000 pizza-supplier-ui:test
How do you do the same thing with react-boilerplate?
Thank you
Ok - here is the answer to my own question after hours of research and trial & error.
For production build, webpack will compile your js files and bundle them up in build/ directory.
The API URLs that are referenced as ${process.env.API_URL}/api/query/findPizzaById/ are baked into the compiled js files in the build/ directory.
Therefore this command:
docker run -e "API_URL=HELLOWORLD" -d -p3000:3000 pizza-supplier-ui:test
has absolutely no effect. It does however register API_URL as an environment variable on the running docker image. The problem here is that API_URL is defined at BUILD TIME, using the environment variable FROM where the build has run.
If anyone has struggled with this issue and have a solution I'd appreciate your enlightenment!
Thanks

Sharing code between React Native + Node

I am using React Native and Node.js. I want to share code between the two. My folder structure is as so.
myreactnativeapp/
mynodeserver/
myshared/
In the react native and node apps I have included the
package.json
"dpendencies" : {
"myshared": "git+https://myrepository/ugoshared.git"
}
This can then be included in each project via require/import etc. This all works fine and for production I'm happy with it. (Though I'd love to know a better way?)
The issue I'm facing is in development it's really slow.
The steps for a change to populate are:
Make changes in Shared
Commit Changes to git
Update the npm module
In development, I really want the same codebase to be used rather than this long update process. I tried the following:
Adding a symlink in node_models/shared - doesn't work in react-native package mangaer
Using relative paths ../../../shared - doesn't work in react-native package mangaer
Any other ideas?
Update 1
I created a script.sh which I run to copy the files into a local directory before the package manager starts. It's not ideal but at least I only have to restart the packager instead of messing with git etc.
#myreactnativeapp/start.sh
SOURCE=../myshared
MODULE=myshared
rm -rf ./$MODULE
mkdir ./$MODULE
find $SOURCE -maxdepth 1 -name \*.js -exec cp -v {} "./$MODULE/" \;
# create the package.json
echo '{ "name": "'$MODULE'" }' > ./$MODULE/package.json
# start the packager
node node_modules/react-native/local-cli/cli.js start
Then in my package.json I update the script to
"scripts": {
"start": "./start.sh",
},
So, the process is now.
Make a change
Start/Resetart the packager
Automatic:
Script copies all .js files under myshared/ -> myreactnativeapp/myshared/
Script creates a package.json with the name of the module
Because I've added the package.json to the copied files with the name of the module, in my project I can just include the items the same as I would if the module was included via the package manager above. In theory when I switch to using the package in production I wont have to change anything.
Import MyModule from 'myshared/MyModule'
Update 2
My first idea got tiresome restarting the package manager all the time. Instead i created a small node script in the shared directory to watch for changes. Whenever there is a change it copies it to the react native working directory.
var watch = require('node-watch')
var fs = require('fs')
var path = require('path')
let targetPath = '../reactnativeapp/myshared/'
watch('.', { recursive: false, filter: /\.js$/ }, function(evt, name) {
console.log('File changed: '+name+path.basename(__filename))
// don't copy this file
if(path.basename(__filename) === name) {
return
}
console.log(`Copying file: ${name} --> ${targetPath+name}`);
fs.copyFile(name, targetPath+name, err => {
if(err) {
console.log('Error:', err)
return;
}
console.log('Success');
})
});
console.log(`Starting to watch: ${__dirname}. All files to be copied to: ${targetPath}`)

Vue.js Webpack Template in a Docker Container: How do I add Webpack-Dev-Server --watch-poll flag?

I am running the webpack / webpack-dev-server portion of the base Vue.js Webpack template (https://github.com/vuejs-templates/webpack/) inside of a docker container I created. The container also contains the vue CLI in order to create new projects (you can get my container here if you want: https://hub.docker.com/r/ncevl/webpack-vue/).
Hot-reload does not work after moving from the webpack-simple template to this one.
Everything was working using the Webpack-Simple template which you can clone / see over here: https://github.com/vuejs-templates/webpack-simple
I was able to get the simple template running (with hot-reload working as intended) with the following webpack-development-server launch command:
webpack-dev-server --hot --inline --progress --host 0.0.0.0 --watch-poll
That said the full (not simple) version of the webpack template does not appear to use a webpack-dev-server launch command and instead appears to use additional middleware as referenced in build/dev-server.js (https://github.com/vuejs-templates/webpack/blob/master/template/build/dev-server.js) and the webpack dev config.
Since the --watch-poll was the key to getting the WDS hot-reload functionality to work within a docker container in the last project, my thinking is that I need to do something similar with the webpack-hot-middleware but I dont see anything in their docs (over here: https://github.com/glenjamin/webpack-hot-middleware) that talks about changing to a polling based approach.
I am not 100% sure the polling flag will do the trick since I can see the container recompile my source when I make a change. I can also see the change in my browser if I refresh it manually.
Whats stranger still is if I inspect my page in browser within chrome dev tools, and then head over to network / XHR I can see that the browser actually does receive information from the webpack-dev-server, but visually it does not update.
Give the above I assume websockets (or socket.io which I think is used) are working and communicating between the browser and the WDS so maybe this is a browser caching issue of some sort?
I checked in my console and found this so it is looking like a header issue:
For reference the text error from that image (to make it easier for anyone having the same issue to find this post) is:
EventSource cannot load http://__webpack_hmr/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://0.0.0.0:8080' is therefore not allowed access.
Again the Hot-Reload / Hot Module Reload was working with this identical container setup when using the webpack-simple Vue.js template.
I am wondering if anyone has run into anything similar or has any ideas on how to add the polling option . I guess my alternative would be roll back to a more basic webpack config and rebuild that portion of things to use the traditional webpack-dev-server / webpack config but give the above I am not sure that is going to fix it.
I am adding this as a separate answer since it more specifically answers the question in the title, while my other answer more specifically explains what solved my actual problem.
The vue.js webpack template project (which can either be init'd from the Vue CLI or pulled from its repo over here: https://github.com/vuejs-templates/webpack) separates its config files into several different directories.
I am posting this answer so that anyone who runs into the need to add polling to their project will be able to understand how / where to do that.
The base project structure for a Vue.js webpack template project looks like this:
The files that you care about if you are messing with trying to get hot module reload working are related to creating your server primarily with webpack-dev-middleware. The most important files related to that are highlighted here:
Basically if you want to add the polling code to the webpack-dev-middleware server you need to be in the /build/dev-server.js file on lines 20 to 24 that look like this:
var devMiddleware = require('webpack-dev-middleware')(compiler, {
publicPath: webpackConfig.output.publicPath,
quiet: true
})
To add polling you would add it just before or after quiet: true. As a side note, if you are having trouble with HMR I would change "quiet:true" to queit false to get a more verbose read out of whats going on from webpack-dev-middleware. I have included verbose and polling modifications to the above code here:
var devMiddleware = require('webpack-dev-middleware')(compiler, {
publicPath: webpackConfig.output.publicPath,
quiet: false, //Changed to for additional verbosity
watchOptions: { //Add Polling
aggregateTimeout: 300,
poll: 1000
}
})
My other answer is in regards to what ended up solving my problem, not necessarily how to actually add polling (which might be necessary for someone else but did not end up being needed to make my dockerized setup work).
It should also be noted that sometimes when HMR (webpack hot module reload) is not detecting changes it is due to the fact that webpack-hot-middleware or webpack-dev-middleware is running into an issue whereby some invisible characters are / were added to the name of the base project directory (probably by someone building the base Vue project) and therefore webpack on certain OSes is not able to see the changes.
If that happens to you and you are on OSx or running webpack inside of a docker container and you can't get HMR to detect changes, try to rename your vue-webpack project directory and it should work.
Ok. So I can't really take credit for this one since it was actually answered by Discuss user Cristian Pallarés over here: http://webpack.github.io/docs/webpack-dev-server.html#combining-with-an-existing-server
Christian says:
I was just trying the same. I just use "php artisan serve" on localhost:8000, and Webpack Dev Server on localhost:3000. You should make this:
set your webpack config "output.publicPath" as "http://localhost:3000/static/" instead of "/static/"
make your php application load this:
The key is the output.publicPath being absolute. Now, you should run "php artisan serve" and launch your webpack dev server too (in my case I use gulp).
Basically I took that and dug through the Vue.js Webpack Template files to locate the config file where webpack was looking for the public path. the public path setting ended up being in the index.js file located in the /config directory of the template.
I changed my code to look like this:
assetsSubDirectory: 'http://localhost:8080/static/', //!!Changed from /static/
assetsPublicPath: 'http://localhost:8080/', //!!Changed from /
As opposed to the previous setting which DID NOT WORK and looked like this:
assetsSubDirectory: '/static/',
assetsPublicPath: '/',
After that I was able to see my changes hot reload while running the vue.js Webpack template from within my docker container.

Within Docker VM, Gulp-Watch Seems to not work well on volumes hosted from the host OS

So I have a setup, probably as most people have, where their app code is mounted into a Docker container through a separate volume.
The problem is that if I run gulp, and specifically gulp-watch, to watch for file modifications etc. within docker, on the app code mounted within the docker container, to properly build and restart node within the docker container as necessary, it seems to get cpu intensive (as in polling for file changes instead of listening for file change events) to the point where my machine buckles.
I think this is due to a limitation of having the file system mounted from the native host to the docker container but how are folks working around this? Are they doing all of their work in the container? Native host then constantly building? Or am I missing something where my setup is incorrect with gulp-watch / nodemon?
For anyone using gulp4
The only way I could get this to work is to use usePolling like below
gulp.watch('./**/*', {interval: 1000, usePolling: true}, gulp.series('superTask'));
Try changing the gulp.watch options. This has been much better for me:
gulp.watch('./**/*', {interval: 1000, mode: 'poll'}, ['build']);
You should use the plugin gulp-watch instead of gulp.watch. The latter uses stat polling, which is much too heavy for the shared file system. gulp-watch uses inotify events to watch the file system on OSX.
The previous answer of usePoll: true didn't work. This one did:
gulp.watch('./**/*', {interval: 1000, usePolling: true}, ['build']);
Jesse's answer didn't work for me, but it was really close. Now, the option seems to be:
gulp.watch('./**/*', {interval: 1000, usePoll: true}, ['build']);
The mode field has been switched out for the usePoll field flag.
See the API section for more details.
In a docker container that has a nodemon installed (npm i -g nodemon) there is an alternative to gulp watch.
Let's say that one wants to watch changes to a swagger.yaml file in ./swagger/swagger.yaml and convert it to a project.json file for use with swagger UI.
Assuming that the correct node modules are installed, or that a stand-alone yaml to json convert tool is installed, one could run the following:
nodemon -L --watch ./editor/api/swagger/* --exec "node ./cvt_yaml_to_json.js"
where:
./editor/api/swagger/* is the directory to watch for file changes
"node ./cvt_yaml_to_json.js" is the command to execute (it can be an arbitrary command). In this case it is a JavaScript script which depends on js-yaml module (npm i js-yaml) and performs YAML to JSON conversion like this:
const yaml = require("js-yaml");
const path = require("path");
const fs = require("fs");
const swaggerYamlFile = "/api/project/editor/api/swagger/swagger.yaml";
const swaggerJsonFile = "/api/project/project.json";
//Converts yaml to json
const doc = yaml.safeLoad(fs.readFileSync(swaggerYamlFile));
fs.writeFileSync(swaggerJsonFile, JSON.stringify(doc, null, " "));

Resources