I want to reference my package version in a npm script so I can show current version in the app.
Something like
{
"name": "bla",
"version": "1.0.0",
"author": "bla bla",
"scripts": {
"build": "node VERSION=<<package.version>> build/build.js"
}
}
Is there a way to do this?
1) Referencing package version in npm-scripts.
In npm-script's you can reference the version using the variable npm_package_version. For example:
Using a bash shell (E.g. Linux, macOS):
{
...
"version": "1.0.0",
"scripts": {
"build": "echo $npm_package_version"
}
}
Note the $ prefix
Using Windows (E.g. cmd.exe, Powershell):
{
...
"version": "1.0.0",
"scripts": {
"build": "echo %npm_package_version%"
}
}
Note the % prefix and suffix
Cross platform
To utilize one syntax cross-platform check out the package cross-var
2) Referencing package version in node script.
The package version can also be referenced in your a app/node script (i.e. build.js) as follows:
const VERSION = process.env.npm_package_version;
console.log(VERSION); // --> 1.0.0
3) Replacing a placeholder string in a .js file with package version.
Another way to achieve this is to specify a placeholder text string within your JavaScript file. Lets say we have a file named build.js and within that file we have a variable named VERSION declared as follows:
// build.js
const VERSION = '#VERSION#'
As you can see, the placeholder text string is #VERSION#.
You can then install and utilize the package called replace in an npm-script as follows:
{
...
"version": "1.0.0",
"scripts": {
"add-version": "replace -s \"#VERSION#\" $npm_package_version build/build.js"
}
}
Running npm run add-version will replace the instance of #VERSION# with the package version (i.e. 1.0.0), in the file named build.js. This solution will hard-code the npm package version into the resultant file.
Note: The to string in the add-version script (above) currently uses the $ prefix (i.e. $npm_package_version) to access the variable, so this will only run successfully on a bash shell. However, for cross-platform usage you'll need to use cross-var as explained in section one (above). In which case the add-version script can be defined as follows:
{
...
"version": "1.0.0",
"scripts": {
"add-version": "cross-var replace -s \"#VERSION#\" $npm_package_version build/build.js"
}
}
Related
This is what i have in my package.json file, in the scripts section:
{
"version": "0.0.1",
},
"scripts": {
"dev-wip": "environment=DEV --tags=#wip"
}
This is how my command line:
npm run dev-wip
I have no problem accessing variables in the package.json file, by doing this:
var pjson = require('../../../package.json');
console.log('version - ' + pjson.version);
I want to be able to access the environment parameter (print the value, for example) that i got from the command line.
I found the solution.
Using this will give my the value of the "environment" parameter (which is "DEV" in my example).
process.env.environment
Is there a way to setup a local folder to be used as package.json repository. The goal is to be able to use the cloud repository (https://www.npmjs.com/package) but the modules which are not found there to be searched and installed from a local folder.
Example package.json:
{
"name": "myproject",
"version": "0.0.0",
"dependencies": {
"standard-npm-module": "1.0.0", // installed from https://www.npmjs.com/package/standard-npm-module
"local-module": "1.0.0", // installed from local folder because it wont be found in https://www.npmjs.com/package/local-module
}
}
PS Yarn or npm any solution will be OK.
you can use local paths. for instance, see the package.json snippet below.
{
"name": "baz",
"dependencies": {
"bar": "file:../foo/bar"
}
}
you can also leverage npm, for instance:
npm install --save /path/to/module
All our server projects contain a git submodule folder (let's say modules), which contains our custom modules/components.
Such module dependencies are installed locally (see serverApp/package.json) so that we don't have to include the whole submodule folder to the final rpm. What I'm having trouble with is limiting the number of files included in node_modules.
The submodule structure looks like the following:
modules
|--loader
|--dist => compiled js files here that are created when installing the module
|--ts => contains typescript files that shouldn't be included in node_modules
|--package.json
|--tsconfig.json
|--more modules
|--.gitignore
Adding an .npmignore file inside modules/loader doesn't seem to help as the whole folder is copied.
modules/loader/tsconfig.json:
{
"compilerOptions": {
"target": "es6",
"module": "commonjs",
"declaration": true,
"outDir": "./dist",
"strict": true
}
}
modules/loader/package.json:
{
"name": "loader",
"version": "1.2.0",
"private": true,
"description": "",
"main": "dist/index.js",
"types": "dist/index.d.ts",
"scripts": {
"preinstall": "npm run build",
"build": "../../node_modules/typescript/bin/tsc",
"test": "echo \"Error: no test specified\" && exit 1"
},
"dependencies": {
"#types/lodash": "^3.9.3",
"#types/nomnom": "0.0.28",
"#types/yamljs": "^0.2.30",
"lodash": "^3.9.3",
"nomnom": "^1.8.1",
"yamljs": "^0.2.1"
},
"devDependencies": {
"typescript": "~2.3.4"
}
}
serverApp/package.json:
{
"name": "my-server-app",
"version": "2.3.0",
"description": "",
"main": "myServerApp.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1"
},
"license": "private",
"dependencies": {
"loader": "file:modules/loader"
},
"devDependencies": {
"grunt": "^0.4.5",
"grunt-cli": "^0.1.13"
}
}
I'm not sure if it has to do with the fact that we have a .gitignore file or because the module is not published and installed locally.
npm version => 5.3.0
EDIT
Doesn't work with specifying the "files" in modules/loader/package.json either
As after checkout the issue I found out below useful points which need to mention out :
We use a .npmignore file to keep stuff out of your package.
If there's no .npmignore file, but there is a .gitignore file, then npm will ignore the stuff matched by the .gitignore file.
If you want to include something that is excluded by your .gitignore file, you can create an empty .npmignore file to override it.
Like git, npm looks for .npmignore and .gitignore files in all subdirectories of your package, not only the root directory.
Similar to .gitignore file .npmignore also follow these rules
Blank lines or lines starting with # are ignored & Standard glob patterns work.
You can end patterns with a forward slash / to specify a directory.
You can negate a pattern by starting it with an exclamation point !.
By default, the following paths and files are ignored, so there's no need to add them to .npmignore explicitly
Additionally, everything in node_modules is ignored, except for bundled dependencies. npm automatically handles this for you, so don't bother adding node_modules to .npmignore.
Testing whether your .npmignore or files config works
If you want to double check that your package will include only the files you intend it to when published, you can run the npm pack command locally which will generate a tarball in the working directory, the same way it does for publishing.
And you can also checkout same issue here Consider methodologies for reducing the number of files within node_modules #14872
Thanks.
Did you checked with node 0.6.13 / npm 1.1.9? This issue is common in npm 1.1.4 .
have a look on this link
You mentioned that you do not want to include "whole submodule" into the "final rpm", by which I presume the package you will finally prepare. I reproduced similar setup and added a '.npmignore' to ignore "submodule" which I installed using npm install --save ./task_in where 'task_in' was my module kept along side of the main package's('task') 'package.json'.
And when the final package was prepared using npm pack while being in the 'task' folder, I got a package(a tar file) without the folder('task_in') as indicated in the '.npmignore'.
While working, though, I found that the module 'task_in' folder was copied to 'node_modules' which is automatically not included in the final package( refer here). Also, while the package is prepared, ".gitignore" is over-ridden by ".npmignore".
So, this is my "two cents" and I hope it helps you.
I'm using npm run to build a javascript file through browserify. Before building, I would like it to create a directory in my build folder, named after the version listed in the package.json. Here is a trimmed example of my package.json:
{
"name": "My App",
"version": "0.0.0-pre-alpha",
"description": "App desc",
"main": "index.js",
"dependencies": {
"browserify" : "*",
}
"scripts": {
"prebuild": "mkdir -p build/$npm_package_version",
"browserify" : "browserify ./src/index.js ./build/$npm_package_version/js/myapp-$npm_package_version.js",
"build" : "npm run prebuild && npm run browserify"
}
}
The code executed in prebuild is:
mkdir -p build/$npm_package_version
But I want it to execute
mkdir -p build/0.0.0-pre-alpha
What am I doing wrong?
Update:
Turns out you can't use arguments with mkdir in a script. So i ended up using the mkdirp npm module.
Old post:
For others looking for an answer: Turns out when you are working in windows the correct way to use the variables is
%npm_package_version%
So the final code should look like:
"prebuild": "mkdir -p build/%npm_package_version%"
Are there any established patterns for running less via npm scripts?
for instance, in my package.json file I have:
{
"name": "lesstest",
"description": "less test",
"main": "dist/index.js",
"scripts": {
"build:css": "./node_modules/less/bin/lessc src/less/app.less dist/style.css"
},
"devDependencies": {
"less": "^2.6.0",
}
}
running:
./node_modules/less/bin/lessc src/less/app.less dist/style.css
from terminal works just fine, but when I run
npm run build:css
I get " '.' is not recognized as an internal or external command,
operable program or batch file. " Does this mean that commands in npm scripts cannot include paths? If so, are there any techniques out there to execute a similar intention without using gulp?
You can just use "lessc src/less/app.less dist/style.css"
By default, package.json looks in your node_modules folder, and if it can't find it, looks elsewhere, so you can safely use a downloaded dependency as if you had globally installed it.
I just want to clarify #JRJurman's answer a bit. You can use lessc like this:
{
"name": "lesstest",
"description": "less test",
"scripts": {
"build:css": "lessc src/less/app.less > dist/style.css"
},
"devDependencies": {
"less": "^3.0.0",
}
}
As a more comprehensive pattern for less in npm: You often need to also integrate less file dependencies. The package.json would look like this:
{
"name": "lesstest",
"description": "less test",
"scripts": {
"build:css": "lessc src/less/app.less > dist/style.css"
},
"devDependencies": {
"less": "^3.0.0",
},
"dependencies": {
"#foo/bar": "^1.0.0"
}
}
and in your local baz.less file you would refer to the dependency like this:
#import "#foo/bar/src/a-less-file";
#foo refers to the respective folder within your node_modules
folder and bar/src are the nested folders.
a-less-file refers
to a-less-file.less within your node_modules/#foo/bar/src