I want to set my Grunt.js file to launch my MAMP server on grunt serve.
I have been trying to use this tutorial here to do this:
https://coderwall.com/p/kwne-g
I was then planning to use this tutorial to set up grunt watch:
http://darrenhall.info/development/yeoman-and-mamp
Now I am having trouble with step one. I have successfully installed grunt exec. However, grunt claims not to be able to find the task 'serverup'.
Here is my code:
grunt.task.run([
'clean:server',
'concurrent:server',
'autoprefixer',
'connect:livereload',
'serverup',
'watch',
'serverdown'
]);
If you followed the examples at the link, it looks like your targets should be exec:serverup and exec:serverdown for the tasks to work.
The problem here and with many other Grunt related questions is that without the full Gruntfile, "answers" are largely guesses. Configuration, task loading, and task registration are all related and without seeing all three, it is difficult to say "this is the answer".
Given that, here's a checklist I use for problems like this when using Grunt and packages from NPM:
Is the code that supports the task installed? Did I forget npm install? Did I miss
errors on install (check npm-debug.log if it exists)?
Have I correctly used grunt.loadNpmTasks for the plugin? Is the line in my Gruntfile and
did I get the plugin name spelled correctly? Did I or my IDE accidentally use to
grunt.loadTasks when I need loadNpmTasks?
Have I correctly named/used grunt.registerTask for the task? If I need to call a
specific target for a task, do I have the the name correctly specified?
If there are paths involved and things are broken, do I have my globbing patterns correctly specified? If a cwd
is involved, do I have the other paths or files correctly specified?
Did I get the configuration right? (This is where things get too plugin-specific for a
checklist.)
Related
This was originally a Github Issue in the Dart-Code repository.
1. Context
I've been working on a package that has hundreds of tests, so an easy way of visualizing code coverage would be incredibly handy.
I would like to run my tests with, say, a .vscode configuration with an lcov.info output which would automatically be recognized by VS Code and highlighted on the respective editors with either red or green.
2. What I've Already Tried
I've tried many different solutions in the past few days — months actually — but none of them worked as the ideal one described above:
flutter test --coverage --coverage-path=lcov.info does work to generate the necessary file, but it's clunky to have to visualize it through a 3rd party program such as genhtml, all the more if you're on Windows.
And it does need Flutter in the end, which should not be necessary if you're working on pure Dart...
IntelliJ would supposedly work ideally, but I just can't seem to enable the Run with Coverage button on mine, even after installing the test_coverage package.
Though one person on Gitter told me he has it working on his IntelliJ.
Both the coverage and the test_coverage packages offer something close to what I described above, but their solutions are way clunkier — and on Windows they are tough to set up...
codecov.io is an alternative with a 3rd party, but it's annoying to have to handle this externally when the editor offers a much more flexible and faster experience.
And there is also the problem of ambiguous coverage, which is not clear with respect to codecov.io. For example, if one folder tests stuff that indirectly calls another folder, does that count as coverage for the indirectly called folder as well? That's almost always undesirable.
3. Other Resources
There's this old question on StackOverflow that was helpful initially.
You can take the genhtml.perl script here.
If you have Git for Windows installed on your machine, you already have Perl installed, it should be here: <git-install-dir>\usr\bin\perl.exe
Replace backslash characters (\\) with slash characters (/) in all file path lines (prefixed with SF:) in the lcov.info file.
Run genhtml.perl script. For example — assumed current working directory is root directory of your project —:
<git-install-dir>\usr\bin\perl.exe \
C:\Scripts\genhtml.perl \
-o .\coverage\html .\coverage\lcov.info
Note. It may be useful also to add the --prefix option.
As a result of these actions, you should get generated HTML report in the .\coverage\html/ directory. Open .\coverage\html\index.html file in your browser to see the report.
I hope this helps — at least, it worked for me.
Edit:
Summary, I tried to follow only the steps listed in the below two links as applies to windows:
https://github.com/mapbox/mapbox-gl-js/blob/master/CONTRIBUTING.md
https://github.com/stackgl/headless-gl#windows
Here I have reattached the screenshot of the commands that I had problems with:
https://imgur.com/RCQCNU5
One more step I took that I should mention is I also did not find the headless gl when I downloaded the repository, when the install headless gl command did not work I manually copied the file and put it in my local copy under the nodemodules directory thinking it would work but it didnt solve anything. I do think this is related to access issues but I dont know what else I should try to get it working?
First, let's clarify your problem: you want a version of mapbox-gl.js which contains a recently fixed bug.
Your best option is to just wait a couple of weeks for a release.
Failing that, you should build your own, from master. You don't need to set up a debug server for that. You can skip straight to the "Creating a Standalone Build" section.
If the steps for building on Windows don't work for some reason, you could set up a local virtual machine running Ubuntu and use that.
But honestly, just wait a couple of weeks. :)
Just in case some one else need to run this on local server.
After clone
Run npm install
npm run start-debug
It will start listening on port 9966.
Test the debug html files entering to
localhost:9966/debug/FILE_NAME_TO_TEST.html
I would like to create a test suite which will be run with karma against my app which is using webpack to build itself. I have two entrypoints, app and vendors. These are set up through my webpack.config.js file here. The resulting bundle.js should contain both of these entrypoints in its generated file.
My karma (mocha) tests residing in test/spec/*_spec.js are currently pointing to specific components, via require statements like:
var app = require('../src/scripts/App')
They also utilize react/jsx which seems to be causing problems during the test run where I get jsx errors:
Module parse failed: /Users/dmarr/src/status/test/spec/app_spec.js Line 10: Unexpected token <
You may need an appropriate loader to handle this file type.
I'd like to keep test runs quick as possible as well as fast build times for testing with webpack-dev-server during development by minimizing babel transforms to only where needed.
What do I need to do in karma.conf.js to get my builds working? Here is the karma.conf.js file I'm playing around with.
Note, that I do have this working without breaking out the vendor bundle here: https://github.com/bitwise/status
Thanks for any help,
Dave
In a similar setup, disabling CommonsChunkPlugin (for testing only) worked for me. Give it a shot!
Alright, so just a disclaimer I suspect this question will be a duplicate of another question however I'm not even sure what to search for.
I have never used Eclipse or Golang before and am attempting to get a basic hello world application to work.
I have installed the goclipse plugin, created a new go package and go command source file. From what I have read to run a project in Eclipse you right click the package, select Run as then set the run configurations. The problem occurs when I attempt to select the go package as none shows up and if I leave it blank it throws a 'Go package not found' exception.
Thank you for any help you can provide.
EDIT: Upon the answers advice I have decided to go with the basic command line, however a friend did also recommend LiteIDE. I will "assume" tmichels answer is correct in regards to getting Go to work within eclipse.
If you don't use the GOPATH environment variable and you don't put your project folder under $GOPATH/src the compiler won't find it. As I see it goclipse lets you skip the GOPATH entirely but in this case you have to put your code under the src directory that you can see in the Project Explorer. See the related section of the goclipe documentation.
Although I think you make your life harder by using a full-fetched IDE for go development. Just use the command line tools. And it has the added benefit that you will actually understand what's going on (IDEs hide this from you).
So for building you can use go build or go install. The latter will copy the binary to your $GOPATH/bin directory. For running test just call go test or go test path/to/package. There is a hidden gem in the go tool: when you are working with multiple packages in the same directory you can use go test ./... to test all of them at once. This also works with other go commands.
I've just picked up CoffeeScript and I'm struggling to understand the deployment workflow. It seems you constantly have to compile the .coffee files before using them. (Yes, I'm aware that you can have it embedded in the browser, but that's not recommended for production applications).
Does one have to constantly (manually) compile the files before deploying? (For example, if using Eclipse, a simple Ctrl+S saves and deploys the .war/.ear on the local machine's server.) Do we have to change the build scripts (for a central, possible CI server) for deploying .coffee files? Is there anyway to have integrated compiling via the IDEs (Eclipse/Netbeans)
Any ideas/pointers/examples on this? How/what have you used in the past?
I call browserify in my Cakefile to pre-compile and package my CoffeeScript for the browser. For an example of how I call browserify as well as coffeedoc and coffeedoctest take a look at the Cakefile for my Lumenize project.
If you are using express or some other node based server, you can have your CoffeeScript compiled at request time, using tools like NibJS or as described in The Little Book on CoffeeScript (Applications chapter), you can use Stitch. BTW, I highly recommend, The Little Book. The "Compiling" chapter has information about Cake and compiling that might help you.
Yes, you should have a build script. Most CoffeeScript projects use a Cakefile for this; see, for example, 37signals' pow. With a Cakefile, you can just run
cake build
from the command line to run the build task in the Cakefile.
You can run the Cakefile on a CI server, assuming that you have Node and CoffeeScript installed on that server.
Don't deploy the coffee files, use something like "coffee -cwj" to constantly watch and compile the .coffee files into javascript (.js) files and deploy those.
The options are c=compile, w=watch and j=join the files.
See the coffee-script web site for details of the options you can pass in.