I'm using Budo to develop a website using Browserify and Babelify like this:
budo src/index.js:static/bundle.js --live -- -t [ babelify --presets [ es2015 ] ]
That works great, except the generated static/bundle.js isn't actually saved to disk - it's just accessible in the browser. If I remove the path argument:
budo --live -- -t [ babelify --presets [ es2015 ] ]
Then it just serves a local file in static/bundle.js but doesn't regenerate it.
How do I get it to actually generate and save the file?
I'm sure you've moved onto other things, but why would you want to save it to disk anyway?
But take a look at this build file I created if you really need to:
build.js
Related
Why would the following command fail?
npm run "start:desktop -- --app word"
says:
npm ERR! Missing script: "start:desktop -- --app word"
I have ensured that start:desktop script exists in scripts section of package.json. If I remove the arguments part, it runs okay, so there is something I need to do with the -- --app word part.
Note: This need to be run from launch.json, but I was trying to run it directly in the console to see what was failing.
If it matters, this is a Yeoman-based Office.js project.
Edit
I understand that because of the use of double-quotes, npm run thinks that the entire value start:desktop -- --app word is the name of the script and therefore can't find it. The problem however is that this is being invoked as a task from my debug configuration (launch.json) and there is no way of separating the arguments from the script name there. Here is the task definition:
{
"label": "Debug: Word Desktop",
"type": "npm",
"script": "start:desktop -- --app word",
"presentation": {
"clear": true,
"panel": "dedicated",
},
"problemMatcher": []
}
This is where I'm stuck. How do I tell it where the name of script ends and the arguments begin. I thought those double-dashes served exactly that purpose, but apparently they don't.
Since your command contains quotes, it is treating everything inside the quotes as a single argument.
There is a script called start:desktop, but there is no script called literally start:desktop -- --app word
Try:
npm run start:desktop -- --app word
I am trying to change the logo following: https://doc.oroinc.com/frontend/storefront/how-to/how-to-replace-the-logo/ . I followed the steps to create an empty bundle, the bundle shows up in the symfony "active bundles" list so it seems to have registered correctly.
The theme definition in: Resources/views/layouts/my_theme/theme.yml :
label: My Theme
logo: bundles/companytheme/my_theme/images/mainlogo.svg
parent: default
groups: [ commerce ]
also seems to work, the "My Theme" is available in the backend>System>Configuration>Commerce>Design>Theme
But the logo doesn't work, there is just nothing. So I looked into public/bundles/ and noticed there is no symlink to the Resource files of my bundle.
Running
php bin/console assets:install --symlink
works, but it only shows the symlinks that are already there
Firstly make sure that you put your logo image into public folder like:
NEW_BUNDLE/package/Resources/public/img/logo.svg/.
Then add a logo property with value from public folder: bundles/NEW_BUNDLE/images/mainlogo.svg into theme.yml and clear the application cache and rerunning the command:
rm -rf var/cache/*
php bin/console assets:install --symlink
A project that respects the semver directory structure for build artefacts is beginning soon, and package.json or .nmprc would seem to be the right place to define this metadata. This is some preliminary code that demonstrates how the goal is intended to be achieved:
{
"name": "com.vendor.product"
, "version": "0.0.0"
, "directories": {
"build": "./out"
}
, "main": "./${npm_directories_build}/${npm_package_name}/${npm_package_version}/${npm_package_name}.js"
, "exports": "${npm_package_main}"
, "scripts": {
"echo": "echo\"${npm_package_exports}\""
}
}
I expected
npm run echo
to print the compound variable result to standard output,
./out/com.vendor.product/0.0.0/com.vendor.product.js
but instead, it prints the literal text
${npm_package_export}
I attempted to use array variables in .npmrc
outpath[]=./out
outpath[]=/${npm_package_name}
outpath[]=/${npm_package_version}
But
...
{
"echo": "echo \"${npm_config_outpath}\""
}
Simply prints an empty newline
It was expected that package.json supports compound variables, but this assumption is now in question. I have checked documentation, but either I am missing something or such is not defined. Long hand repetition of the same data is to be avoided (e.g. multiple references to package variables in order to make a single path). It is intended for package name and version to always dictate the location of the build files in a reliable and predictable manner.
If compound variables are not supported, could you clarify how .npmrc array variables actually work? Failing that, could you recommend an alternative method to achieve the same ends? Many thanks!
Searched documentation:
https://docs.npmjs.com/misc/config
https://docs.npmjs.com/files/npmrc
https://docs.npmjs.com/configuring-npm/npmrc.html
https://docs.npmjs.com/files/package.json#config
http://doc.codingdict.com/npm-ref/misc/config.html#config-settings
https://github.com/npm/ini
Short Answer:
"Does package.json support compound variables?"
Unfortunately no, not for the way you are wanting to use them. It only has package json vars which can be used in npm scripts only. For example on *Nix defining the echo script as:
"echo": "echo $npm_package_version"
or on Windows defining it as:
"echo": "echo %npm_package_version%"
will print the version e.g. 0.0.0.
Note: cross-env provides a solution for a single syntax that works cross-platform.
You certainly cannot include parameter substitution ${...} elsewhere in package.json fields except for the scripts section.
Additional info:
Regarding your subsequent comment:
How array values defined in .npmrc can be used in package.json
AFAIK I don't think you can. For example let's say we;
Save this contrived .npmrc in the root of the project directory.
.npmrc
quux[]="one"
quux[]="two"
quux[]="three"
foo=foobar
Then cd to the project directory and run the following command to print all environment variables:
npm run env
As you can see, the npm_config_foo=foobar environment variable has been added by npm. However for the quux array there is no npm_config_quux=[ ... ] environment variable added.
So, in npm scripts using package.json vars the following does work:
"echo": "echo $npm_config_foo"
However the following, (for referencing the array), does not - simply because it does not exist;
"echo": "echo $npm_config_quux"
The ini node.js package:
Maybe consider investigating the ini node.js package that npm utilizes for parsing .npmrc files. For example:
If you run the following command to install the package in your project:
npm i -D ini
Then define the npm echo script as per this:
"scripts": {
"echo": "node -e \"var fs = require('fs'), ini = require('ini'); var config = ini.parse(fs.readFileSync('./.npmrc', 'utf-8')); console.log(config.quux)\""
}
Note it uses the nodejs command line option -e to evaluate the JavaScript code. It essentially executes the following:
var fs = require('fs'),
ini = require('ini');
var config = ini.parse(fs.readFileSync('./.npmrc', 'utf-8'));
console.log(config.quux);
Then given the contrived .npmrc file that I mentioned previously when running:
npm run echo
it will print:
[ 'one', 'two', 'three' ]
Is there a way to programmatically run a sketch plugin on a sketch file from the command line, in any language?
For example: runCommand --file myfile.sketch --plugin myscript.js
Would run the plugin myscript.js on myfile.sketch
Thank you!
This was added in Sketch 43 & above
$ sketchtool run
Usage: sketchtool run <bundle> <command> [ --application=<path> | -A <path> ] [ --new-instance{=YES|NO} | --no-new-instance | -N {<YES|NO>} ] [ --wait-for-exit{=YES|NO} | --no-wait-for-exit | -W {<YES|NO>} ] [ --context=<string> | -C <string> ]
Run a command from a plugin, inside Sketch.
Arguments:
bundle plugin bundle containing the command to run
command the command to run
Options:
--application The version of Sketch to launch. If not supplied, the default is to use the version containing sketchtool. (optional).
--new-instance Launch a new instance of Sketch, even if one is already running. (optional, defaults to NO).
--wait-for-exit Wait for Sketch to exit before returning from this command. (optional, defaults to NO).
--context JSON dictionary of values to pass in to the plugin. (optional).
I'm working on AIX and have a process that keeps crashing. I've never examined core files, and would like some guidance if possible. I'm using dbx. How can I (a) make sure the core file is going where I want it to go and (b) see the state of the process before it crashed?
Thanks!
I do okay stepping through a run but also am not sure about debugging a core.
I found these commands are probably the ones to focus on. There are probably more.
Once you have your core running in dbx:
'where' -- to show the stack
'up' or 'down' -- to move through the frames and then you
'print var' -- display the variables
and 'list' or 'edit' -- will display the file information at that current location
Looking here under "Examining Data" helped me out.
core files are created in the current working directory of a process. Check with getcwd(), set with chdir().
dbx [ -a ProcessID ] [ -B DebugFile ] [ -c CommandFile ] [ -I Directory ] [ -E DebugEnvironment ] [ -p oldpath=newpath:...| pathfile ] [ -u ] [ -F ] [ -r ] [ -x ] [ -v ] [ -C CoreFile | ObjectFile [ CoreFile ] ]
Load your program into dbx with dbx /path/to/progname /path/to/corefile and you can start looking at your stack trace ("where" command, etc).
If you don't specify a corefile dbx will automatically load a matching file named "core" if its in the same directory as the program loaded (and they match signatures).
Read the man page on dbx, it gives all the debugging commands you'll need.
Also note that your program will have needed to be compiled with debugging symbols enabled (and not later 'strip'ed) in order for the stack trace to be the most useful. Without debugging symbols you'll see the function names in the stack trace, but not much else.