VueJS PWA: service worker nog working. Maybe due to .htaccess file? - apache

I've build a PWA with vue. Everything is working fine in development and when I deploy to chrome webserver. Service worker is registrated and running. So far so good.
When I deploy to production, service worker isn't running due to the fact that the scope or start_url is not matching manifest.json (thats what google dev tools tells me).
I believe it's due to the fact that I'm running vue-router in history mode and have a .htaccess file running on production to rewrite rules as recommended here.
I've also tested this to switch back to hash mode in vue-router and deploy to production again. Then service worker is working just fine.
To overcome this problem I've tried to set the scope in manifest.json and service worker to index.html:
register(`${process.env.BASE_URL}service-worker.js`, {
registrationOptions: { scope: 'index.html' },
ready () {
console.log(
'App is being served from cache by a service worker.\n'
)
}
})
The same for manifest.json:
{
"name": "myapp",
"short_name": "myapp",
"theme_color": "#4DBA87",
"icons": [
{ "src": "./img/icons/android-chrome-192x192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "./img/icons/android-chrome-512x512.png", "sizes": "512x512", "type": "image/png" },
{ "src": "./img/icons/android-chrome-maskable-192x192.png", "sizes": "192x192", "type": "image/png", "purpose": "maskable" },
{ "src": "./img/icons/android-chrome-maskable-512x512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
],
"start_url": "index.html",
"scope": "index.html",
"orientation": "portrait",
"display": "standalone",
"background_color": "#000000"
}
But still chrome gives me the message about scope being not in sync.
Any thoughts on this?

Add to package.json config for pwa plugin:
"vue": {
"pwa": {
"workboxOptions": {
"exclude": [
".htaccess"
]
}
}
}
UPDATE:
This action excludes .htaccess file from SW cache.
So, your SW won't crash and won't attempt to download .htaccess file from server.
At least, I faced with same problem and found this StackOverflow topic without answer. So, I read Vue PWA doc and found this, working for me, way.

Related

updating manifest.json file doesn't change lighthouse report errors react native

I'm trying to make the desktop version of a react-native app a PWA.
I keep encountering the same report:
lighthouse report
{
"short_name": "test",
"name": "test",
"start_url": "/index.html",
"icons": [
{
"src": "favicon/favicon-512.png",
"sizes": "512x512",
"type": "image/png",
"purpose":"any"
}
,{
"src": "favicon/favicon-144.png",
"sizes": "144x144",
"type": "image/png",
"purpose":"any"
}
],
"app":{
"urls": [
"http://localhost:19006/"
],
"launch": {
"web_url": "http://localhost:19006/"
}
},
"loading":"loading_screen.gif",
"display": "standalone",
"theme_color": "#1E88B5",
"background_color": "#f2f7fc",
"scope": "/"
}
This is the root directory:
folder structure
Any feedback would be appreciated!
I tried changing the value to the "src" property for the icons, but the changes are not reflected in the lighthouse report. I also cleared the browser cache.
P.S: other checks in the lighthouse report pass but not the installability one.
Are you re-creating a production build (usually with npm run build) each time you update the manifest.json file?

Chaostoolkit istio extension hangs when playing experiment

I'm trying to use the chaos toolkit istio extension, my problem is as follows:
I have a experiment.json file which contains a single probe to retrieve a virtual service. The file looks similar to the following:
{
"version": "1.0.0",
"title": "test",
"description": "N/A",
"tags": []
"secrets": {
"istio": {
"KUBERNETES_CONTEXT": {
"type": "env",
"key": "KUBERNETES_CONTEXT"
}
}
},
"method": [
{
"type": "probe",
"name": get_virtual_service:,
"provider": {
"type": "python",
"module": "chaosistio.fault.probes",
"func": "get_virtual_service",
"arguments": {
"virtual_service_name": "test"
"ns": "test-ns"
}
}
}
}
I have set KUBERNETES_CONTEXT and http/https proxy as env vars. My authorisation is using $HOME/.kube/config.
When playing the experiment it validates the file fine and tries to perform the action but becomes stuck and just hangs until it times out.
The error I see in the logs is a HTTPSConnectionPool error (failed to establish a new connection, operation timed out).
Am I missing any settings? All help appreciated.

Debugging Vue in VScode and Chrome, unbound breakpoint

I'm trying to debug a Vue website I'm writing in VSCode and Chrome.
When I put a breakpoint in the data() { return {...} } function it stops on it, but if I try to put it in a method in a Vue file or a JS service, once I launch Chrome through the debug config the breakpoints become unbound. Does anyone have any ideas about how to keep the breakpoints bound?
This is my config file:
"version": "0.2.0",
"configurations": [
{
"name": "Launch Chrome",
"request": "launch",
"type": "pwa-chrome",
"url": "http://localhost:8080",
"webRoot": "${workspaceFolder}/client/meet-for-lunch/src",
"sourceMapPathOverrides": {
"webpack:///src/*": "${webRoot}/*"
}
},
{
"type": "node",
"request": "launch",
"name": "Debug server",
"runtimeExecutable": "nodemon",
"program": "${workspaceFolder}/server/bin/www",
"restart": true,
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen",
"skipFiles": [
"<node_internals>/**"
]
}
]
}
I'm including the debug config for the server because in works.
Here is an example of a method I'm trying to debug (from the Vue file), I put a break point at this.error = null . The method runs normally so I expect it to stop at the breakpoint :
methods: {
async login() {
try {
this.error = null;
const response = await AuthenticationService.login({
email: this.email,
password: this.password
})
this.$store.dispatch('setToken', response.data.token)
this.$store.dispatch('setUser', response.data.user)
}
catch (err) {
console.log(`An error has occured: ${JSON.stringify(err.response)}`)
this.error = err.response.data.error
}
}
}
I'm also trying to debug my service:
login(credentials) {
return Api().post('/login', credentials)
}
The Api object just creates the Axios request
Thanks,
Ben
https://www.codegrepper.com/code-examples/javascript/vuejs+vscode+unbound+breakpoint
After a whole day of searching this solved my problem
{
"version": "0.2.0",
"configurations": [
{
"name": "WSL Chrome",
"type": "chrome",
"request": "launch",
"url": "http://localhost:8080",
"webRoot": "${workspaceFolder}/src",
"sourceMapPathOverrides": {
"webpack:///./src/*": "${webRoot}/*",
"webpack:///src/*": "${webRoot}/*"
}
}
]
}
When I had Unbound Breakpoints in VSCode I ended up needing to start the process with the --inspect or --debug-brk=5858 flag. Beyond that, launch.json gave me lots of trouble, and these resources helped
https://code.visualstudio.com/docs/nodejs/nodejs-debugging
https://code.visualstudio.com/docs/nodejs/debugging-recipes
https://github.com/microsoft/vscode-recipes/tree/master/nodemon
https://code.visualstudio.com/docs/typescript/typescript-debugging
launch.json examples:
{
"type": "node",
"request": "attach",
"name": "Node: Nodemon",
"processId": "${command:PickProcess}",
"restart": true,
"protocol": "inspector",
},
{
"name": "Launch tests via NPM",
"type": "node",
"request": "launch",
"cwd": "${workspaceRoot}",
"runtimeExecutable": "npm",
"runtimeArgs": [
"run-script", "testDebug"
],
"port": 5858
}
package.json
"scripts": {
"start": "NODE_PATH=./src DEBUG=express:* NODE_ENV=dev nodemon -w src --ext ts --exec node --inspect -r tsconfig-paths/register -r ts-node/register src/index.ts",
"testDebug": "NODE_ENV=test ts-mocha --debug-brk=5858 --paths -p tsconfig.json",
}
},
Well, it's not really an answer but I've restarted my Node server a couple of (more) times and now it stops at the breakpiont. I hope that the problem doesn't return. Now he doesn't show the value of the variables for some reason but I guess that's another problem.
Thanks for the help :)
Ben
I had the same issue in my vueJS project. Something to try before making any changes to files etc which solved it for me:
In the ClientApp/App folder: 1.Delete the node_modules folder 2.Delete the package-lock.json file 3.Open a cmd prompt for your ClientApp/App folder 4.Use the cmd "npm i"
This final step will reinstall all your node-modules. The issue I had must've been a conflicting node-module.
As of May 2022...
A note if you're using vscodium and firefox you need to install firefox-devtools directly from the marketplace: https://marketplace.visualstudio.com/items?itemName=firefox-devtools.vscode-firefox-debug
Beyond that the launch.json config is standard:
{
"name": "Vue:Client",
"type": "firefox",
"request": "launch",
"url": "http://localhost:3000",
"webRoot": "${workspaceFolder}/src",
"pathMappings": [
{
"url": "file://",
"path": ""
}
]
},
The extension suggested I insert those pathMappings.
See https://github.com/firefox-devtools/vscode-firefox-debug/issues/267

AWS Code Build - cached DOWNLOAD_SOURCE taking too long

I am trying to improve the build speed of one of my projects on CodeBuild. The project uses a Github source provider and source caching of type local is enabled.
The first time I ran the build it took 103 secs. I ran it again immediately after the first one finished expecting it to run in a few seconds due to source caching, but it took 60 secs.
What I am missing here? Is the cache not working? If it is working, why does it take that long on the second run?
Thanks
Project Details:
{
"projectsNotFound": [],
"projects": [
{
"environment": {
"computeType": "BUILD_GENERAL1_LARGE",
"imagePullCredentialsType": "SERVICE_ROLE",
"privilegedMode": true,
"image": "111669150171.dkr.ecr.us-east-1.amazonaws.com/***********/ep-build-env:latest",
"environmentVariables": [
{
"type": "PLAINTEXT",
"name": "NEXUS_URI",
"value": "http://***************"
},
{
"type": "PLAINTEXT",
"name": "REGISTRY",
"value": "111669150171.dkr.ecr.us-east-1.amazonaws.com/*********"
}
],
"type": "LINUX_CONTAINER"
},
"timeoutInMinutes": 60,
"name": "StorefrontApi",
"serviceRole": "arn:aws:iam::111669150171:role/CodeBuild-ECRReadOnly",
"tags": [],
"artifacts": {
"type": "NO_ARTIFACTS"
},
"lastModified": 1571227097.581,
"cache": {
"type": "LOCAL",
"modes": [
"LOCAL_DOCKER_LAYER_CACHE",
"LOCAL_SOURCE_CACHE",
"LOCAL_CUSTOM_CACHE"
]
},
"vpcConfig": {
"subnets": [
"subnet-fd7f958b"
],
"vpcId": "vpc-71e3f414",
"securityGroupIds": [
"sg-19b65e6c",
"sg-9e28e9f9"
]
},
"created": 1571082681.262,
"sourceVersion": "refs/heads/ep-mysql",
"source": {
"buildspec": "version: 0.2\n\nphases:\n build:\n commands:\n - env\n - cd extensions\n - mvn --settings $CODEBUILD_SRC_DIR_DEVOPS_WINE/pipelines/storefront/build-war/settings.xml --projects storefront/ext-storefront-webapp -am -DskipAllTests clean install\n\nartifacts:\n secondary-artifacts:\n storefront-war:\n base-directory: $CODEBUILD_SRC_DIR/extensions/storefront/ext-storefront-webapp/target\n files:\n - \"*.war\"\n\ncache:\n paths:\n - '/root/.m2/**/*'\n - '/root/.npm/**/*'",
"insecureSsl": false,
"gitSubmodulesConfig": {
"fetchSubmodules": false
},
"location": "https://github.com/*****************.git",
"gitCloneDepth": 1,
"type": "GITHUB",
"reportBuildStatus": false
},
"badge": {
"badgeEnabled": false
},
"queuedTimeoutInMinutes": 480,
"secondaryArtifacts": [],
"logsConfig": {
"s3Logs": {
"status": "DISABLED",
"encryptionDisabled": false
},
"cloudWatchLogs": {
"status": "ENABLED"
}
},
"secondarySources": [
{
"insecureSsl": false,
"gitSubmodulesConfig": {
"fetchSubmodules": false
},
"location": "https://github.com/*****************.git",
"sourceIdentifier": "DEVOPS_WINE",
"gitCloneDepth": 1,
"type": "GITHUB",
"reportBuildStatus": false
}
],
"encryptionKey": "arn:aws:kms:us-east-1:111669150171:alias/aws/s3",
"arn": "arn:aws:codebuild:us-east-1:111669150171:project/StorefrontApi",
"secondarySourceVersions": [
{
"sourceVersion": "refs/heads/staging",
"sourceIdentifier": "DEVOPS_WINE"
}
]
}
]
}
Apparently, at time of writing, CodeBuild does not use the native git client to fetch the source from GitHub. I understand that the CodeBuild internal teams have an internal feature request to move from whatever they're using to the native git client to improve performance.
Does your repository, by change, have lots of large files in its history? You can use this answer for a command to run to analyze your repository.
If you have lots of large files in your history and you're able to remove them, you can then use a tool like BFG Repo Cleaner to rewrite history. That should speed up the DOWNLOAD_SOURCE phase.
Also, if you have a dedicated support plan with AWS, you should reach out to your TAM to upvote the feature request to move to native git for GitHub source downloads.

Loopback - redirect all traffic to index.html

I'm building a react single page application using for backend, loopback.
How can I set, in the middleware, all the traffic (except API calls to the server and asset files like css, js,...) to go to index.html?
Here is what I have for the moment in my middleware.json configuration for the files page.:
"files": {
"loopback#static": [
{
"paths": [
"/storage"
],
"params": "$!../storage"
},
{
"paths": [
"/*"
],
"params": "$!../client/index.html"
},
{
"paths": [
"/*.*"
],
"params": "$!../client"
}
]
},
At the moment, it seems like all traffic is indeed redirected to index.html but so are the css, js, ...
Any ideas?