grunt faster loading tasks - loading

Is there anybody who can tell me how to get grunt tasks load faster.
I really want to reduce the loading time, because most tasks require 1 second to load.
Especially for 'watch' task. when I am watching for changes, I really want to compile sass much faster.
Any ideas?
Thanx

You are really looking for this: jit-grunt.
Instead of loading all tasks every time, jit-grunt will only load those that are necessary.

Had the same problem as the OP: grunt watch was very slow for compiling .less files and liveReload so here's what I did:
install time-grunt to show execution times for each task:
$ npm install --save-dev time-grunt
and then place this line right after module-exports:
module.exports = function(grunt) {
require('time-grunt')(grunt);
After running grunt you will notice which tasks took longer than others. In my case it was loading all dependencies on every file change, so I found this solution:
install jit-grunt to load dependencies on demand instead of loading all of them each time grunt performs a task.
$ npm install jit-grunt --save-dev
and replace the initial loader in the gruntfile
require('load-grunt-tasks')(grunt);
with
require('jit-grunt')(grunt);
This saved my liveReload time for .css updates from ~1600ms to ~250ms.
PS: #curist suggested jit-grunt as well but I thought that more details might help anyone.

If your grunt is in a Vagrant virtualbox, you can synchronize via nfs, which is a bit faster than the default sharing. (but still way slower than a native filesystem)
In your Vagrantfile:
config.vm.synced_folder ".", "/vagrant", type: "nfs"
On my machine, time for grunt to load tasks (with ssd):
native: ~1s
nfs: ~4s
default Vagrant sharing: ~16s

Same problem here, after changed and execute task all modules was reload.
But i found a very good solution on github
(https://github.com/steida/grunt-este-watch)
What's wrong with official grunt-contrib-watch?
It's slow and buggy, because it uses combination fs.fileWatch and fs.watch, for historical reason. From Node 0.9.2+, fs.watch is ok.
What to do?
install grunt-este-watch
npm install grunt-este-watch --save-dev
change contrib watch
grunt.loadNpmTasks('grunt-contrib-watch');
to este watch
grunt.loadNpmTasks('grunt-este-watch');
change task
watch: {
javascript: {
files: 'src/js/**/*',
tasks: ['uglify']
}
}
to
esteWatch: {
options: {
dirs: ['../src/**/*']
},
'js': function(filepath) { return 'uglify' }
}

It sounds like your computer is the problem here, you will not have many options but to upgrade.
The only thing I can think of is concurrent tasks, if you can run the tasks concurrent you might shave some time off.
You could use grunt-concurrent as said on the repo:
Running slow tasks like Coffee and Sass concurrently can potentially improve your build time significantly. This task is also useful if you need to run multiple blocking tasks like nodemon and watch at once, as seen in the example config.
You can also load the tasks only when needed with this trick.

Related

`Cannot use e "__Schema" from another module or realm.` and `Duplicate "graphql" modules` using ApolloClient

I have a React application with ApolloClient with Apollo-Link-Schema. The application works fine locally but in our staging environment (using GOCD), we get the following error:
Uncaught Error: Cannot use e "__Schema" from another module or realm.
Ensure that there is only one instance of "graphql" in the node_modules
directory. If different versions of "graphql" are the dependencies of other
relied on modules, use "resolutions" to ensure only one version is installed.
https://yarnpkg.com/en/docs/selective-version-resolutions
Duplicate "graphql" modules cannot be used at the same time since different
versions may have different capabilities and behavior. The data from one
version used in the function from another could produce confusing and
spurious results.
at t.a (instanceOf.mjs:21)
at C (definition.mjs:37)
at _ (definition.mjs:22)
at X (definition.mjs:284)
at J (definition.mjs:287)
at new Y (definition.mjs:252)
at Y (definition.mjs:254)
at Object.<anonymous> (introspection.mjs:459)
at u (NominationsApprovals.module.js:80)
at Object.<anonymous> (validate.mjs:1)
Dependencies are installed with yarn, I've added the resolutions field to the package.json.
"resolutions": {
"graphql": "^14.5.8"
},
I've checked the yarn.lock and can only find one reference for the graphql package.
npm ls graphql does not display any duplicates.
I thought maybe its a build issue with webpack - I have a different build script for staging, but running that locally I am still able to get the react application to run with that bundle.
Can anyone suggest anything else to help me fix this?
I managed to find the cause of the issue, if this helps anyone else. The issue is not to do with duplicate instances of the package at all, this is a false positive triggered by us using webpack's DefinePlugin to set the process.env.NODE_ENV to staging for our staging build.
However, in webpack the mode (see https://webpack.js.org/configuration/mode/), which sets the process.env.NODE_ENV, only accepts none, development and production as valid values. This was triggering an env check in the graphql package to fail and trigger this error message.
In our case, we need to differentiate between staging and production as our API endpoint differs based on this, but the solution we implemented is to not rely on the process.env.NODE_ENV, but to assign a custom variable on build (e.g. process.env.API_URL)
I would try to replicate the error locally and debug it:
try this:
rm -rf node_modules yarn.lock
# also remove any lock files if you have package-lock.json too
yarn install
# build the project locally and see if you got the error
I got this problem one time where I was working with Gatsby and 2 different themes where using different versions of GraphQL. Also be more explicit with the version (without caret) and check if the error persist.
do you have a repo youc an share? that would also help us to help you :)
While changing NODE_ENV to production might solve the issue, if you have different variables for each environment and don't want to mess with your metrics this is not an ideal solution.
You said you use webpack. If the build with the issue uses some kind of source-map in your devtool, you might want to disable that to see if the problem persists. That's how I solved this without setting my NODE_ENV to production.
I had a similar problem when trying to run Apollo codegen and was able to fix it by deduping my npm packages. Run this:
rm -rf node_modules && npm i && npm dedupe
I was having this problem so I switched to yarn, and after deleting node_modules and npm lockfile, then running yarn, the problem went away :-).
I ended up here because I use the AWS CDK and the NodejsFunction Construct. I was also using bundling with minify: true.
Toggling minify to false resolved this for me.

Unable to debug firebase functions

I am trying to debug my js code the runs on firebase functions.
My steps were:
install from functions
npm install --save #google-cloud/debug-agent
added index.js:
require('#google/cloud-debug').start();
when I tryed to run
firebase deploy --only functions
got an error :
Error: Error parsing triggers: Cannot find module '#google/cloud-debu
g'
Try running "npm install" in your functions directory before deployin
try: ndb firebase serve
debugger breakpoints are hit with stack traces visible, note it's a little slow so give the debugger time to instrument the child processes
Additionally I was able to debug cloud functions in isolation using (caps for removed values):
GCLOUD_PROJECT=THE-FIREBASE-PROJECT node --inspect-brk /path/to/functions-framework --target FUNCTION-NAME --port=5000
where functions-framework simply expands to the full path for the installed functions-framework (global in my case) and the working directory contains the target index.js for functions.
Alternately when or where the FIREBASE_CONFIG is needed try this format adjusted to fit:
FIREBASE_CONFIG="{\"databaseURL\":\"https://YOUR-FIREBASE-PROJECT.firebaseio.com\",\"storageBucket\":\"YOUR-FIREBASE-PROJECT.appspot.com\",\"projectId\":\"YOUR-FIREBASE-PROJECT\"}
https://github.com/GoogleChromeLabs/ndb
https://cloud.google.com/functions/docs/functions-framework
https://github.com/GoogleCloudPlatform/functions-framework-nodejs/issues/15
The addition to index.js should be:
require('#google-cloud/debug-agent').start();
or better:
require('#google-cloud/debug-agent').start({ allowExpressions: true });
We recently renamed the module, and it is possible that the instructions you are following are partially out of date. Can you point us to the instructions you have been following?
Also note that support for debugging cloud functions is experimental at this point. There are certain cases (dependent on the traffic to the function) where you function may finish before the debug-agent has a chance to initialize/register. We're currently looking into how to address this.

Gulp.watch will not keep watching files.

I have the following code,
http://paste.ubuntu.com/6824071/
but when I run 'gulp' in cli it just runs the tasks and quits. It dosen't stay to watch the files and recompile.
Ezras-MacBook-Air:no1fitness-sandbox Ezra$ gulp
[gulp] Using file /www/no1fitness-sandbox/gulpfile.js
[gulp] Working directory changed to /www/no1fitness-sandbox
[gulp] Running 'default'...
gulp.run() has been deprecated. Use task dependencies or gulp.watch task triggering instead.
[gulp] Running 'styles'...
[gulp] Finished 'default' in 8.2 ms
[gulp] Finished 'styles' in 1.85 s
Ezras-MacBook-Air:no1fitness-sandbox Ezra$
The only way I can make it do it is by removing the task around the gulp.watch function.
is this right? Are there better ways (that work)?
Then theres the warning about gulp.run, which I'm confused about as their own docs still seem to use it.
You aren't calling the watch task — you are running the default task:
[gulp] Running 'default'...
Run gulp watch to run your watch task.
I know that the question was answered right, but this post comes from Google while I was searching for my problem and the solution in my case is:
npm install gulp-watch
Hope this saves someone else time ^^
Another cause could be that the directory to watch does not contains any file. In that case 'gulp watch' stops immediately.

SASS fails my build using Grunt on Windows 2008 Server

Running this on Windows Server 2008 R2
Getting error when trying to compile SASS from a Bamboo task. All my other tasks in my Gruntfile work fine, it's just the SASS that is giving this error:
Warning: Unable to write "dist/css/style.min.css" file (Error code: EPERM). Use --force to continue
Bamboo is running as Administrator and all the related pieces were all installed as this user as well.
Here is what I have in my Gruntfile
sass: {
dist: {
options: {
style: 'compressed'
},
files: [{
expand: true,
cwd: 'css',
src: ['**/style.scss'],
dest: 'dist/css/',
ext: '.min.css'
}]
}
}
If I delete my dist/css directory from Windows explorer and run from the command line, it works, but no amount of messing around like that get's it to work from within Bamboo. I'm working around this now by just having my local compiled css in my repository, but really want this as part of our build process.
If anyone could suggest some things to try, I would appreciate it. I'm out of ideas.
So it turns out it was a PATH issue. When we installed Ruby (for SASS) it wrote to the local user PATH. This is fine, except that Bamboo didn't see this change until we rebooted the server. This however created another issue for us. Now that there was something in the local user PATH, Bamboo stopped using the system PATH and started using the local users PATH and everything else stopped working! To fix this we just added to path to Ruby to the system PATH and all was good in the world again.

How do use node-qunit?

The info on this page seems less-than-forth-coming -- https://github.com/kof/node-qunit. I've got a setup where I installed nodejs and installed the node-quit module. I have test runner and executed the command node /path/to/runner.js. Below is an example of my setup. Any ideas or examples on how to do this or maybe I'm using it wrong. I previous ran qunit tests using Rhino and EnvJs without any issues but I figured I try nodejs since I using it for other things and the packaging system can be scripted in my build. Maybe I missing an option to node to include Qunit or some environment variable not set -- that would make sense.
File Structure
node/
public/
js/
main.js
tests/
js/
testrunner.js
tests.js
Installation
cd node
npm install qunit
This will now update the file structure.
node/
node_modules/
qunit/
tests/js/testrunner.js
var runner = require("../../node/node_modules/qunit");
runner.run({
code : "/full/path/to/public/js/main.js",
tests : "/full/path/to/tests/js/tests.js"
});
tests/js/tests.js
test("Hello World", function() {
ok(true);
});
Command
node tests/js/testrunner.js
It appears that you need to use full paths to the main.js and tests.js files and also include a relative path to the qunit module. I updated the code above as an example for others.

Resources