According to the sw-precache documentation https://github.com/GoogleChrome/sw-precache#runtime-caching including configuration for runtime caching for sw-precache should itself take care of including sw-toolbox for runtime caching of dynamic content. I have tried using this with sw-precache's CLI as well as grunt-sw-precache. My configuration for Grunt is as follow:
grunt.initConfig({
'sw-precache': {
build: {
baseDir: './public',
workerFileName: 'service-worker.js',
appendTimestamp: true,
cacheId: 'cnbc-polymer-cache-20',
clientsClaim: true,
directoryIndex: 'index.html',
navigateFallback: 'index.html',
skipWaiting: true,
maximumFileSizeToCacheInBytes: (1024000 * 20),
staticFileGlobs: [
'/src/**/*',
'/index.html',
'/manifest.json',
'/bower_components/**/*',
'/images/**/*.*',
'/favicon.ico'
],
verbose: true,
runtimeCaching: [{
urlPattern: /franchise/,
handler: 'cacheFirst',
options: {
debug: true,
cache: {
maxEntries: 10,
name: 'franchise-cache',
maxAgeSeconds: 180
}
}
}, {
urlPattern: /story/,
handler: 'cacheFirst',
options: {
debug: true,
cache: {
maxEntries: 10,
name: 'story-cache',
maxAgeSeconds: 180
}
}
}]
}
}
});
And when trying with the CLI I used the following sw-precache-config.js:
module.exports = {
baseDir: './public',
workerFileName: 'service-worker.js',
appendTimestamp: true,
cacheId: 'cnbc-polymer-cache-20',
clientsClaim: true,
directoryIndex: 'index.html',
navigateFallback: 'index.html',
skipWaiting: true,
maximumFileSizeToCacheInBytes: (1024000 * 20),
staticFileGlobs: [
'/src/**/*',
'/index.html',
'/manifest.json',
'/bower_components/**/*',
'/images/**/*.*',
'/favicon.ico'
],
verbose: true,
runtimeCaching: [{
urlPattern: /franchise/,
handler: 'cacheFirst',
options: {
debug: true,
cache: {
maxEntries: 10,
name: 'franchise-cache',
maxAgeSeconds: 180
}
}
}, {
urlPattern: /story/,
handler: 'cacheFirst',
options: {
debug: true,
cache: {
maxEntries: 10,
name: 'story-cache',
maxAgeSeconds: 180
}
}
}]
};
All configuration options other than the runtimeCaching options are being applied to the generated service-worker.js file.
My package.json is configured to use "^4.2.3", of sw-precache, and "^3.4.0" of sw-toolbox.
I have not seen anyone else commenting of having this problem. Can anyone comment on what might be the issue preventing sw-precache from respecting my runtimeCaching options?
sadly grunt-sw-precache does not depend on the newest sw-precache which causes the runtimeCaching option and other improvements how sw-precache handles things like requestsRedirects correctly to be missing.
I made a clone of the repo and the necessary changes here. I have no intention on publishing this to npm, but as a temporary solution (so refer to my github repo in your package.json!)
Please check and make sure that you have done Grunt Installation.
grunt-sw-precache can be installed using the following command:
$ npm install grunt-sw-precache --save-dev
enabled grunt-sw-precache by adding the following to your Gruntfile:
grunt.loadNpmTasks('grunt-sw-precache');
Then, you might want to try using handler: 'networkFirst' instead of handler: 'cacheFirst'.
As mentioned in this tutorial,
Try to handle the request by fetching from the network. If it succeeds, store the response in the cache. Otherwise, try to fulfill the request from the cache. This is the strategy to use for basic read-through caching.
You may visit this GitHub post for more information on how and why you'd use sw-precache and sw-toolbox libraries together and also The offline cookbook for more information on caching strategies.
Related
I am working with the gatsby-source-wordpress plugin
If I hard code my API keys/secret into my Gatsby.config, everything works fine, but I want to add these as .env variables so that I can .gitignore for deployment, and this is where things are breaking.
At the root of my directory, I have a .env file which looks like this
CLIENT_SECRET=10987654321
CLIENT_ID=123456
USER=secret#secret.com
PASS=mypassword1
I'm then try to access these in gatsby.config, like this
require('dotenv').config({
path: `.env.${process.env.NODE_ENV}`
});
module.exports = {
siteMetadata: {
title: 'Gatsby Default Starter',
},
plugins: [
{
resolve: 'gatsby-source-wordpress',
options: {
baseUrl: 'myurl.com',
protocol: 'http',
hostingWPCOM: true,
useACF: false,
auth: {
wpcom_app_clientSecret: `${process.env.CLIENT_SECRET}`,
wpcom_app_clientId: `${process.env.CLIENT_ID}`,
wpcom_user: `${process.env.USER}`,
wpcom_pass: `${process.env.PASS}`,
},
},
},
{
resolve: `gatsby-plugin-emotion`,
},
'gatsby-plugin-react-helmet',
{
resolve: `gatsby-plugin-manifest`,
options: {
name: 'gatsby-starter-default',
short_name: 'starter',
start_url: '/',
background_color: '#663399',
theme_color: '#663399',
display: 'minimal-ui',
icon: 'src/images/gatsby-icon.png', // This path is
relative to the root of the site.
},
},
'gatsby-plugin-offline',
],
}
which is returning the following errors when I run either gatsby develop or gatsby build
source and transform nodesThe server response was "400 Bad Request"
source and transform nodesThe server response was "403 Forbidden"
Inner exception message : "User cannot access this private blog."
No routes to fetch. Ending.
So, the issue is the .env variables don't seem to be pulling through properly, but I can't see a reason why they wouldn't be? Is there anything I've missed in setting this up?
Gatsby doesn't know which plugin you mean (see How to use) and your overall syntax is wrong. The plugins is an array for example.
module.exports = {
plugins: [
{
resolve: "gatsby-source-wordpress",
options: {
auth: {
wpcom_app_clientSecret: process.env.CLIENT_SECRET,
wpcom_app_clientId: process.env.CLIENT_ID,
wpcom_user: process.env.USER,
wpcom_pass: process.env.PASS,
}
}
}
]
}
This should work assuming that you also define the other necessary fields mentioned in the README.
Mup version (1.4.3):
module.exports = {
servers: {
},
meteor: {
// TODO: change app name and path
name: 'e-commerce',
path: '../../store', //diff
servers: {
// one: {},
two: {},
three: {},
four: {},
five: {},
six: {},
seven: {}
},
buildOptions: {
serverOnly: true,
cleanAfterBuild: false,
},
env: {
// TODO: Change to your app's url
// If you are using ssl, it needs to start with https://
ROOT_URL: 'https://someurl.com',
MONGO_URL: 'xxx',
},
docker: {
// change to 'kadirahq/meteord' if your app is not using Meteor 1.4
//image: 'abernix/meteord:base',
image: 'abernix/meteord:node-8.4.0-base'
// imagePort: 80, // (default: 80, some images EXPOSE different ports)
},
deployCheckWaitTime: 80,
enableUploadProgressBar: true
}
};
Output of commmand after 2gb / 8 g is filled
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
I have detailed my error in meteor forum here
Turns out not enough memory is located and i need to increase memory as included in here
I need to pass environment Variable when mup runs my app, how do i put that example main.js --node-args="--max-old-space-size=6144"
How do i pass arugments with mup config ?
Any suggestion or help is much appreciated.
I just forked the repo and modified and created a new image. Is running already. Thanks for the hint
I am currently trying to configure grunt-sync to run inside a watch and am running into issues. I've reported the issue to the module's github page but decided to post here to draw upon the general development population rather than wait for a single contributor to come across my issue report.
So, I'm thinking this may just be a gap in my understanding of how to drive grunt tasks through a watch. I've got watches up and running for several tasks already and I'm adding grunt-sync to my workflow to automate publication of my changes to a network directory that blah blah blah...not important; my watch is working for some stuff but not for this. I'm dropping in the relevant config section along with my "concurrent","karma", and "sass" tasks to give you the gist of my overall grunt config.
module.exports = function(grunt){
grunt.initConfig({
pkg: grunt.file.readJSON("package.json"),
project: {
app: 'app',
},
sync:{
main: {
files:
[
{
cwd: 'app/',
src: [
'**/*.js',
'**/*.html',
'**/*.css',
'!app/node_modules/**'
],
dest: ['publish/']
}
],
verbose: true
}
},
karma: {
unit: {
configFile: 'test/karma.conf.js'
},
continuous:{
configFile: 'test/karma.conf.js',
singleRun: true,
browsers: ['PhantomJS']
}
},
sass:{
dev: {
options:{
style: 'expanded',
compass: false
},
files:{
'app/css/app.css':'app/css/app.scss'
}
},
dist: {
options: {
style: 'compressed',
compass: false
},
files:{
'app/css/app.css':'app/css/app.scss'
}
}
},
watch: {
sass: {
files: 'app/css/**/{,*/}*.{scss,sass}',
tasks: ['sass:dev']
},
styles: {
files: ['app/css/app.css'],
tasks: ['autoprefixer']
},
// karma: {
// files: ['test/*.js',
// 'test/**/*.js'
// ],
// tasks: ['karma:unit:run']
// },
livereload:{
options: {livereload: true},
files: ['app/**/*'],
},
sync:{
files: ['app/**'],
tasks: ['sync:main']
}
},
concurrent:
{
target: {
tasks: [
'karma:unit',
'watch'
],
options: {
logConcurrentOutput: true
}
}
}
});
require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks);
grunt.registerTask('default', [
'sass:dev',
'concurrent:target'
]
);
};
Currently receiving the following warning when I grunt
Warning: Task "sync:main" not found. Use --force to continue.
Aborted due to warnings.
Since there is only the main subtask, I thought that maybe changing the watch from executing ['sync:main'] to executing ['sync'] would possibly work. The warning goes away but poof nothing happens...so I'm not sure if the issue is with my config or with the module implementation.
Any ideas?
Edit to Add:
From the module's github site, I see the following in sync.json
{
"main": {
"files": [{
"src": ["**"],
"dest": "bin/to",
"cwd": "bin/from"
}]
}
}
so that would lead me to believe that "main" is the name I should be using for the sync subtask. I'm really confused as to why grunt isn't recognizing it in my config, but I am not too terribly familiar with dissecting the code for grunt modules.
Well...turns out I referenced a module in my gruntfile before I ran npm install on it and then decided to come on the internet to tell everybody about it.
Edit:
To partially exonerate myself, I found the console that I used to run npm install grunt-sync --save-dev. I had run it, but I was in the
wrong directory; it added it to the wrong gruntfile.
To answer my own question, the gruntfile packaged with the [grunt-sync] module contains a watch section, so you just have to have grunt-contrib-watch installed; you don't have to do anything special. And that makes sense. A folder synchronization task would be pretty darned worthless without a file system watch, so it is perfectly reasonable to run the task in a very broad watch but with an inherent blacklist (it watches all files in all folders but only operates on files matching a src pattern.
So to get it to syn-down all files on all file changes,
sync: {
main:{
files:[{
src:[
'**'
]
, dest: 'publish'
}
]
,verbose: true
}
},
will copy all files to the publish subdirectory. I run mine inside a concurrent task
concurrent:
{
target: {
tasks: [
'karma:unit',
'sync:main',
'watch'
],
options: {
logConcurrentOutput: true
}
}
}
Personally, I'll probably be swapping this out with grunt-rsync because grunt-sync simply performs the file copy task inside [sync:main] What I want it to do is to only send deltas to the publish folder every time I save a file; that's a task for rsync.
Below is a part of my Gruntfile. Running '$grunt msbuild:migrate:local' works fine, but '$grunt msbuild:migrate:dev' doesnt seem to be pulling in my ConnectionString property. Am I organizing things correctly for the options in inherit correctly?
msbuild: {
src: ['Web Platform\Web Platform.csproj'],
options: {
projectConfiguration: 'Dev',
targets: ['Clean', 'Rebuild'],
maxCpuCount: 4,
verbosity: 'minimal',
stdout: true,
buildParameters: {
WarningLevel: 2,
DeployOnBuild: false,
Configuration: 'Dev',
},
},
migrate: {
// Defaults -----------------------------------------
src: ['Migrate.msbuild'],
options: {
targets: ['Migrate'],
buildParameters: {
DryRun: 'False',
Verbose: 'False',
RollbackSteps: '1',
},
verbosity: 'minimal',
},
// Tasks -----------------------------------------
local: {
// Uses defaults from above (I hope)
},
dev: {
options: {
buildParameters: {
ConnectionString: 'Data Source=<%= credentials.aws_rds_hostname %>,1433;Initial Catalog=DevDatabase;User ID=<%= credentials.aws_rds_admin_username %>;Password=<%= credentials.aws_rds_admin_password %>'
}
}
}
}
}
Grunt doesn't support deeply nested tasks. The only thing that can run here is "grunt msbuild:migrate" (inheriting the global configuration, overridden by its own config)
See this ticket for example.
Hi I'm trying to achieve the following. I'm using grunt for jshint validating.
Somewhere in a file I have used:
var logger = function () {
// some ode
}
Because logger is never actually used jshint correctly shows me the following error.
W098: 'logger' is defined but never used.
I could set unused to false and it would work perfectly. But I actually want the option to take place in other files and warn me about unused variables. So the unused option is not gonna work for me.
I also saw that I could use a inline comment like this:
* exported EXPORTED_LIB */
But I would actually prefer to avoid cluttering my files with such comments. Is there any chance I can specify an exported options in my grunt file like I can for example for globals.
Heres the jshint part of my gruntfile:
jshint: {
// global options
options: {
camelcase: true,
curly: true,
eqeqeq: true,
forin: true,
immed: true,
indent: 4,
latedef: true,
newcap: true,
noarg: true,
nonew: true,
plusplus: false,
quotmark: 'single',
undef: true,
unused: true,
strict: true,
maxparams: 4,
maxdepth: 4,
trailing: true,
maxlen: 120,
browser: true,
node: true
},
server_logger: {
src: [BASE_PATH_SERVER_LOGGER, '/**/*.js'].join(''),
options: {
browser: false
}
},
client_logger: {
src: [BASE_PATH_CLIENT_LOGGER, '/**/*.js'].join(''),
options: {
node: false,
devel: true
}
}
}
Thanks for your time.
Best regards
Playerwtf
UPDATE: I made an issue on jshint github repository here
This was recently fixxed and works now as I would expect it.
github-issue
As an example I use it like this in my gruntfile
client_logger: {
expand: true,
cwd: BASE_PATH_CLIENT_LOGGER,
src: '**/*.js',
options: {
node: false,
devel: true,
globals: {
logger: true,
expect: true,
it: true,
describe: true,
beforeEach: true,
afterEach: true
},
exported: ['logger']
}
}
But the npm module was not yet updated. If you want this to work you will have to manually copy the newest version from the jshint github repository and replace the one in the current module or wait until it is updated.
i think you can exclude files in your src-files, so you could exclude your logger file from your basic linting (i suppose the logger file is logger.js here), and lint the logger file separatly with the unused-flag turned off.
read more about that here -> "! at the beginning of a pattern will negate the match"
you could set the cwd (and leave the join stuff). see more about that in the docs: Building the files object dynamically
jshint: {
// global options
options: {
... your global options here
},
server_logger: {
options: {
browser: false
},
files: [{
cwd: BASE_PATH_SERVER_LOGGER,
src: ['/**/*.js', '!logger.js']
}]
},
client_logger: {
options: {
node: false,
devel: true
},
files: [{
cwd: BASE_PATH_CLIENT_LOGGER,
src: ['/**/*.js', '!logger.js']
}]
},
lint_logger: {
options: {
unused: false
},
files: [{
src: ['logger.js']
}]
}
}
not 100% sure if that works, but i think it should at least lead you into the right direction. if you need to specify a path and not only a file for excluding you could put your logger-file in a separate folder an just exclude that folder!