I got a simple program off github 1 crlint.js that takes a js file and creates a report identifying various measures like Cyclomatic complexity and Halstead value. I updated my node and npm (I'm on a Mac - Sierra). I added a start line in the script section of the package.json file:
"scripts": {
"start": "node crlint",
"test": "echo \"There is an Error: no test specified\" && exit 1"
}
When I run it in the terminal (input file lib/testutil.js), no errors but no report generated either.
npm start [cyclomatic] —lib/toolutil.js
This comes back (in the terminal):
> crlint#0.1.1 start /Users/cindy/Documents/crlint
> node crlint "lib/toolutil.js"
Any thoughts? This is the first time I've used github so am sure I am missing something. I've looked at the posts on this forum about this - didn't find anything useful. Thanks -
Related
I am undertaking https://www.kubeflow.org/docs/distributions/gke/deploy/deploy-cli/ and at the stage bash ./pull-upstream.sh there is a problem and I have isolated it to a single command inside the scripts:
kpt pkg get https://github.com/zijianjoy/pipelines.git/manifests/kustomize/#upgradekpt upstream
When I run this command alone, I get the same error as when it runs in the script:
Package "upstream":
Fetching https://github.com/zijianjoy/pipelines#upgradekpt
From https://github.com/zijianjoy/pipelines
* branch upgradekpt -> FETCH_HEAD
Adding package "manifests/kustomize".
Fetched 1 package(s).
Error: /home/tester_user/gcp-blueprints/kubeflow/apps/pipelines/upstream/third-party/argo/upstream/manifests/namespace-install/overlays/argo-server-deployment.yaml: wrong Node Kind for expected: MappingNode was SequenceNode: value: {- op: add
path: /spec/template/spec/containers/0/args/-
value: --namespaced}
I made some mistakes following the script during the setup (that I think I corrected) so it could be something I did. It would be good to know why this error is happening even so for my general understanding.
I am on google cloud platform, in the command line prompt that comes built in to the web ui.
SUCCESS
I start PowerShell from the File explorer: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. I change directory to where I want to run the yarn command. I run yarn build which starts the script rollup --config --environment NODE_ENV:production. The application builds successfully.
FAIL
I start PowerShell from the start menu: C:\Users\Me\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Windows PowerShell\Windows PowerShell.lnk. This shortcut targets the executable above: %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe. I change directory to where I want to run the yarn command. I run yarn build. The build errors.
src/renderer/renderer.tsx → app/build...
[!] Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)
src\renderer\renderer.tsx (6:9)
4:
5: document.addEventListener("DOMContentLoaded", () =>
6: render(<App />, document.getElementById("root"))
^
7: );
Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)
at error (C:\Users\Me\Dev\graphics\svgconverter\node_modules\rollup\dist\shared\rollup.js:217:30)
at Module.error (C:\Users\Me\Dev\graphics\svgconverter\node_modules\rollup\dist\shared\rollup.js:15145:16)
at tryParse (C:\Users\Me\Dev\graphics\svgconverter\node_modules\rollup\dist\shared\rollup.js:15034:23)
at Module.setSource (C:\Users\Me\Dev\graphics\svgconverter\node_modules\rollup\dist\shared\rollup.js:15436:30)
at ModuleLoader.addModuleSource (C:\Users\Me\Dev\graphics\svgconverter\node_modules\rollup\dist\shared\rollup.js:17434:20)
at ModuleLoader.fetchModule (C:\Users\Me\Dev\graphics\svgconverter\node_modules\rollup\dist\shared\rollup.js:17495:9)
at async Promise.all (index 0)
at async Promise.all (index 0)
error Command failed with exit code 1.
LOOKING FOR DIFFERENCES
I have checked the file properties of the shortcut. It does not open the target as administrator. The owner is EUR/{Me}. System, Me and Administrators have all permissions checked except for special permissions. I think this is should not lead to any difference in behavior from starting PowerShell without using this shortcut?
I have printed the environment variables on both shells using dir env: | Format-Table -Wrap and they are completely equal.
So now I am scratching my head. What could possibly explain the difference?
So, my understanding is that react-snap as per its features "Works out-of-the-box with create-react-app - no code-changes required."
I read through the documentation and I see that it required some adjusting to work with Google Analytics which I implemented.
However, it also suggests changes to be made if one is going to use the default service worker that comes with CRA.
https://github.com/stereobooster/react-snap#service-workers
However, what is confusing is that it seems one has to perform a EJECT in order to make the necessary change.
navigateFallback: publicUrl + '/index.html',
You need to change this to an un-prerendered version of index.html - 200.html, otherwise you will see index.html flash on other pages (if you have any). See Configure sw-precache without ejecting for more information.
My question is - and note I am quite novice - does one have to eject? I kinda want to keep things simple. The only place I could find this line was in WebPack. navigateFallback
Also, if I don't see the negative side of the flashes on pages as per the documentation, is it okay to omit this step or will it have issues on other things?
Although this question is more than a year old, I'd like to take the opportunity as I've been able to implement service workers in react-snap (although with a varying degree of success).
Here's stereobooster's reference in GitHub:
https://github.com/stereobooster/react-snap/blob/master/doc/recipes.md#configure-sw-precache-without-ejecting
You can configure it without ejecting. What you need to do is the following:
Download and install sw-precache and ugfify-js:
npm install sw-precache uglify-js --save-dev
or
yarn add sw-precache uglify-js -D
Then, in your package.json add the following entries:
(Replace the build script with the following)
"scripts": {
"generate-sw": "sw-precache --root=build --config scripts/sw-precache-config.js && uglifyjs build/service-worker.js -o build/service-worker.js",
"build": "react-scripts build && react-snap && yarn run generate-sw"
}
Then, create a folder in the root level (next to your package.json) called scripts
and add sw-precache-config.js file.
module.exports = {
// a directory should be the same as "reactSnap.destination",
// which default value is `build`
staticFileGlobs: [
"build/static/css/*.css",
"build/static/js/*.js",
"build/shell.html",
"build/index.html"
],
stripPrefix: "build",
publicPath: ".",
// there is "reactSnap.include": ["/shell.html"] in package.json
navigateFallback: "/shell.html",
// Ignores URLs starting from /__ (useful for Firebase):
// https://github.com/facebookincubator/create-react-app/issues/2237#issuecomment-302693219
navigateFallbackWhitelist: [/^(?!\/__).*/],
// By default, a cache-busting query parameter is appended to requests
// used to populate the caches, to ensure the responses are fresh.
// If a URL is already hashed by Webpack, then there is no concern
// about it being stale, and the cache-busting can be skipped.
dontCacheBustUrlsMatching: /\.\w{8}\./,
// configuration specific to this experiment
runtimeCaching: [
{
urlPattern: /api/,
handler: "fastest"
}
]
};
Note, if you're not using an app-shell but you're loading the whole page (Meaning there's no dyanmic content), replace where it says navigateFallback: "/shell.html" with navigateFallback: "/200.html"
This basically allows you to cache the entire page
You can look for more information here:
https://github.com/stereobooster/an-almost-static-stack
One thing that I'd recommend to check (I'm close to start that process as well) is the workbox-sw.
What to do if React-Snap fails
error at / TypeError: Cannot read property 'ok' of null
Or
ERROR: The process with PID 38776 (child process of PID 26920) could not be terminated. \node_modules\minimalcss\src\run.js:13:35)
Reason: There is no running instance of the task.
You may get these infamous errors. I don't know exactly what causes them, but I know they're mentioned here, and here. In this case, delete the build folder, open a new terminal window, and try again.
If the problem still persists, then break down the script:
Do:
"scripts": {
"build": "react-scripts build"
"postbuild": "react-snap",
"generate-sw": "sw-precache --root=build --config scripts/sw-precache-config.js && uglifyjs build/service-worker.js -o build/service-worker.js",
}
And try running them independently.
The following command works as expected:
protractor --cucumberOpts.tags='not #tag1' conf.js
Now I want to add this command as a script to package.json like this:
"scripts": {
"my-script": "protractor --cucumberOpts.tags='not #tag1' conf.js"
}
Running the command npm run my-script gives me the following error:
Usage: protractor [configFile] [options]
configFile defaults to protractor.conf.js
The [options] object will override values from the config file.
See the reference config for a full list of options.
Options:
...
Error: Error: more than one config file specified
Why is that?
Both of the commands seem to be identical.
This is not actually a protractor issue. I was able to recreate this issue and resolved it by using escaped doubles quotes in that script string like so.
"scripts": {
"my-script": "protractor --cucumberOpts.tags=\"not #tag1\" conf.js"
}
This issue (apparently) is to do with how node handles single quotes on different operating systems. There is some more info in this question.
I'm trying to use coffeeify with budo so I do not have to add the extension to my require statements. I have tried passing these commands through budo's browserify options
budo src/app.coffee --live --serve bundle.js -- -t coffeeify --extension=".coffee"
budo src/app.coffee --live --serve bundle.js -- -t [coffeeify --extension=".coffee"]
I also tried inserting the browserify transform into my package.json
"browserify: {
"transform": ["coffeeify", {"extension": ".coffee"}]
}
Here is something that works for me (took me forever to figure it out, the hard part being getting watchify to work with coffeescript). Everything is in the package.yaml. Invoke npm start from your top folder and it will do the trick. npm puts all the locally installed node binaries in your PATH for you (they normally live under node_modules/.bin).
{
"name": "my-package",
"version": "1.0.0",
"private": true,
"scripts": {
"start": "(cd src; budo app.coffee:bundle.js --dir . --live --verbose -- --extension=.coffee | garnish)"
},
"browserify": {
"extension": [ ".coffee" ],
"transform": [ ["coffeeify"], ["brfs"] ]
},
"devDependencies": {
"brfs": "1.4.1",
"browserify": "11.1.0",
"budo": "^5.1.5",
"coffee-script": "latest",
"coffeeify": "^1.1.0",
"garnish": "^3.2.1",
"watchify": "3.4.0"
}
}
I have my source code under the src folder, and a file named app.coffee which includes (or require in node.js terms) my whole application. I have an index.html in my src folder which reference the bundle.js through from an html script tag.
The command to start budo is inside my package.json. It does cd into my src folder first.
The trick is to specify some configuration in the browserify block: the extension .coffee needs to be present, and a list of transforms as well. I tried to have everything on the command line but never got it to work
After npm start is invoked, since I pass the --live argument to budo everything works like magic and edit/saves to my documents do trigger a browser reload/refresh.
To deploy or release you'll probably need another target to minify with uglify.js. I still have a script that does that manually in 2 steps, the first step calls browserify and the second step calls uglify.js explicitely.
As a remark, recent version of budo do the piping into garnish for you I've heard.
Another tip is to look at what the React folks are doing to transform their .jsx files, as it is in theory extremely close to what the coffeescript folks need to do. There seems to be a huge momentum around React so hopefully React people will have figured those build problems first.