I'm trying to set up an npx script to create a template project.
In package.json I have:
"bin": {
"init": "bin/init"
}
In the init script I'm using tag='v'$(npm pkg get version | tr -d '"') to get the version of the package. I then use git clone --depth 1 --branch $tag https://github.com/matriarx/typescript.git to clone that specific repository for that specific tag.
When I do yarn link and try use it locally, from within that specific project, it works because it's able to correctly pick up the package.json version. So the above only works if it's run inside an existing project. However that's not what I want to do.
I want to enable someone to run it even if they have nothing locally, by simply doing npx #matriarx/typescript init and it should create the new project by cloning it. More than that I want them to be able to clone any specific version by using npx #matriarx/typescript#0.0.1 init in order to clone a specific version.
However it seems that anything I try is only able to get the version from a local package.json that already exists.
I could just clone the current existing repository without specifying any tag, but that would defeat the point of having releases, then it would just clone any current code completely disregarding the release. So it has to clone the tagged release.
How can I get the remote package version stored on npm from the bin script without having anything locally before hand?
Alternatively is there a better way to do what I'm trying to do?
EDIT: I ended up just hardcoding the version in the script, which works but it sucks because it's tedious to have to update it every time I bump the version. Though for now I still don't know a better way to do it.
After some more time messing around I figured out there is a standard way of doing it, at least since npm 7.
If you have a project like example then you can create a completely separate project called create-example with a bin script.
When you use npm init example, npm will automatically search for a package prefixed with "create-" and execute its main bin script. So when running npm init example it will search for that create-example package and execute the bin script, which will install the example package.
This is how most of the bigger packages like react and next do it.
This approach comes with some disadvantages that I really don't like, for example it will show the incorrect dependencies on npm and it will cause you to have to maintain multiple projects and semvers on different projects. However it will also allow you to create a clean separation between the actual project and the installation of that project.
For some projects it might also make a lot more sense. For example if you have a project that doesn't have a package.json at all and you want to create a setup for it, it wouldn't make sense to create an npm package inside that project just for that. Instead you can create a separate "create-project" package just to set it up and keep npm out of the actual project. In other words it gives you a neat way to create bin scripts for a completely separate project that doesn't have anything to do with npm.
You could also just have created a normal shell script and execute it using curl but I guess npm just gives you another way to do it.
You still have to hardcode the version in that "create-project" package, I still have not seen a way to automatically determine the version from a remote package. The only way I've managed to do that is to completely download the package, get the version, then delete it, but that would be terrible for people with a slower internet connection or limited data.
(not a native speaker, sorry if things don't seems clear)
We are devs for a clients and we work with others devs from another company. The other devs make us a package that we sometimes change this in it, then submit the changes in a pull request.
So we end up having a local version of the package and the official version. And so we want to use the local version in dev (where we might make little changes in the package to match what the client want), and the official in prod (where our changes and other devs changes are merges).
I will show an example that don't work but that can help understand the idea:
[...]
"dependencies"{
[...]
"package":"prod-package"
},
"devDependencies"{
[...]
"package":"local/version/of/package"
},
and so, we should have this:
npm build # use local/version/of/package
npm build --prod # use prod-package
I'm not really good with npm (in fact, beside npm install and npm remove, I basically know nothing), so I might ask something obvious, but I can't find the answer anywere.
Have you tried using npm-link to link to the local version of the package you are consuming? That way, you could still commit your changes to the package back to the vendor.
https://docs.npmjs.com/cli/v8/commands/npm-link
You would essentially run npm link in the checked-out-from-VCS (git?) package folder, then you switch back to your project where you are consuming that package and run npm link {name-of-npm-package}
This would allow you to develop on that version locally, make your changes (and they will show up on VCS for easy pull request management).
I am getting this when I am trying to push my code into github actions or building dockerimage.
shell: /usr/bin/bash -e {0}
npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion#1, but package-lock.json was generated for lockfileVersion#2. I'll try to do my best with it!
I tried to implement this Link it works but again after some commit I am getting the same error and I have to repeat the same procedure again and again.
Any fix for that?
Look in your .gitignore if you have the lines :
package-lock.json
node_modules/
if not,then add them,
after that look in your Github repository and delete the package-lock.json file and the node_modules directory (if any)
Important Edit :
My bad, Kevin Martin is right the official documentation tell us to add it to the repository for CI/CD.
This file is intended to be committed into source repositories, and
serves various purposes:
Describe a single representation of a dependency tree such that
teammates, deployments, and continuous integration are guaranteed to
install exactly the same dependencies.
Provide a facility for users to "time-travel" to previous states of
node_modules without having to commit the directory itself.
To facilitate greater visibility of tree changes through readable
source control diffs.
And optimize the installation process by allowing npm to skip repeated
metadata resolutions for previously-installed packages.
But for my case (Azure Devops) i had a lot of trouble with it.
I have a NPM package with a small user base, yesterday I created a new version and wanted to release it. I thought that I might as well make use of the new GitHub Packages and so I setup everything as GitHub suggested and released!
Now the problem is that I still have the old NPM page running on version 2.0.2 while everyone currently uses this as their dependency while the new GitHub package is on 2.0.4, Is there a way to 'synchronize' these two. Of course the GitHub Packages uses the <USER>/<PACKAGE> labeling while NPM just uses <NAME>.
Is the only thing I can do to publish on GitHub Packages and on NPM and just try to move users away from the NPM page?
If your publishing a public package, your better off just publishing it on NPM, as that is what most developers are used to.
I use GitHub Packages at work and the only advantage is that is effective free for hosting internal packages, as we are already paying for GitHub anyway. If it wasn’t for the zero price we wouldn’t be using it.
If you really want to force all your users to migrate to GitHub packages, and have to set up npm to work with it you could mark you old version npm deprecated and use that to point people to the new version.
https://docs.npmjs.com/cli/v6/commands/npm-deprecate
Here is another solution, but there is a catch.
Change your registry.npmjs.org package content to
index.js
export * from '#schotsl/my-package';
Now your registry.npmjs.org package is (almost) pointing to your npm.pkg.github.com package.
Only almost because any development directory for a project downstream of registry.npmjs.org/my-package, must configure the scope-to-server mapping for #schotsl/my-package to npm.pkg.github.com in a package manager config file.
In the case of package managers 'npm' and 'yarn' (v1) that can be done in
an .npmrc file at the same level as package.json.
The required .npmrc content is
#schotsl:registry=https://npm.pkg.github.com
# Github PAT token, packages:read authorization only ok
//npm.pkg.github.co/:_authToken="ghp_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
The first line is the scope to server mapping.
The second line is a Github personal authorization token (PAT) with at least package:read permission. It is actually pretty liberal. A PAT with package:read issued from any github account will allow read access to every github accounts packages.
For the 'yarn' v2 package, the .npmrc file does not work, and instead a couple of keys need to be set in .yarnrc.yml.
Unfortunately there is no way to set the scope-to-server mapping and the token inside the registry.npmjs.org/my-package package itself.
Putting the .npmrc file in there doesn't work, it is ignored. And that wouldn't be a good solution anyway, because not all package managers read .npmrc files.
That is the 'catch' - using npm.pkg.github.com packages requires package manager specific config settings to be made by every downstream developer.
In addition, what if two different upstream packages have colliding scope names, each mapping to a different server? The current config methodology fails in that case.
Feature Proposal not current behavior
Ideally, there would be a common interface agreed upon by all package managers inside package.json - and the scope-to-server mapping would be defined in the package that directly references the scope. For example, in the package.json of my-package on registry.npmjs.org
{
dependencies:{
"#schotsl/my-package":"1.0.0"
},
registries:{
"#schotsl/my-package":"https://npm.pkg.github.com",
},
auths:{
"https://npm.pkg.github.com":"ghp_XXXXXXXXXXXXXXXX",
},
}
Then downstream users would not need to config for each scope, and predictable (and risky) problems with scope name or package name collisions would not occur.
But that is not the way it is. Therefore Github Packages (npm.pkg.github.com) doesn't really seem to be a feasible way to provide public packages which may become dependencies of other public packages. No problem for private packages though.
When I search for packages on NPM, I would like to see package sizes (in KB or MB, etc). NPM doesn’t seem to show this information.
How can I determine how much bloat an NPM package will add to my project?
What you probably want to measure is the impact a package has if you were to add it to your app bundle. Most of the other answers will estimate the size of the source files only, which maybe inaccurate due to inline comments, long var names etc.
There is a small utility I made that'll tell you the min + gzipped size of the package after it gets into you bundle -
https://bundlephobia.com
Take a look at this cost-of-modules project. It's an npm package that will list the size of a package and number of children.
Installation:
npm install -g cost-of-modules
Usage:
Run cost-of-modules in the directory you are working in.
I created Package Phobia early this year with the hope to get the package size information into npmjs.com and also track package bloat over time.
https://packagephobia.com
This is designed to measure disk space after you run npm install for server-side dependencies like express or dev dependencies like jest.
You can read more about this tool and other similar tools in the readme here: https://github.com/styfle/packagephobia
Update 2020
The "Unpacked Size" (basically Publish Size) is available on the npmjs.com website along with "Total Files". However, this is not recursive meaning that npm install will likely be much bigger because a single package likely depends on many packages (thus Package Phobia is still relevant).
There is also a pending RFC for a feature which prints this information from the CLI.
In case you are using webpack as your module bundler have a look at:
webpack-bundle-analyzer
webpack-bundle-size-analyzer
I definitely recommend the first option. It shows size in interactive treemap. This helps you to find the size of package in your bundled file.
The other answers in this post show you size of the project, but you might not be using all parts of the project, for example with tree shaking. Other approaches then might not show you accurate size.
I've created a tool, npm download size, which inspects tarball size for a given npm package, including all tarballs in the dependency tree. This gives you an idea of the cost (install time, disk space, runtime resources, security audit, ...) of adding the dependency up front.
In image above, Tarball size is tar.gz of package, and Total size is size of all tarballs. The tool is pretty basic, but it does what it says.
A cli tool is also available. You can install it like this:
npm i -g download-size
And use it like this:
$ download-size request
request#2.83.0: 1.08 MiB
The source code is available on Github: api, cli tool and web client.
Try to use package-size.
npx package-size vue,vue-router,vuex react,react-dom,react-router,redux
https://github.com/egoist/package-size
howfat is one more tool which can show total package size:
npx howfat jasmine
If you use Visual Studio Code, you could use an extension called Import Cost.
This extension will display inline in the editor the size of the imported package. The extension utilizes webpack with babili-webpack-plugin in order to detect the imported size.
You could check out npm-module-stats. It is an npm module that gets the size of an npm module and its dependencies without installing or downloading the module.
Usage:
var stats = require("npm-module-stats");
stats.getStats("glob").then((stack) => {
let dependencies = Object.keys(stack);
let totalSize = dependencies.reduce((result, key, index) => {
return result + stack[key].size;
}, 0);
console.log('Total Size in Bytes ', totalSize);
console.log('Total Dependencies ', dependencies.length-1);
}).catch((err) => {
console.error(err);
});
It might seem a little verbose but it solves the problem you described appropriately.
Before publishing the npm package, You can check the size of the package using the following command.
npm publish --dry-run
I have attached the result of my npm package.
A "quick & dirty" way is to use curl and wzrd.in to quickly download the minified package and then grep the file size:
curl -i https://wzrd.in/standalone/axios#latest | grep Content-Length
The download is minified but not gzipped, but you get a good idea of the relative size of packages when you compare two or more of them.
I prefer https://github.com/aholachek/bundle-wizard all the way since it was released.
It works on deployed sites: npx bundle-wizard reddit.com
It works on your local project:
For multi-page apps/sites adjust the last line with the path you want to check.
npm run build
npx serve -s build
npx bundle-wizard localhost:5000/
The interactive view is really helpful in discovering what's where.
In order to check the impact of different packages on your bundle. You can check out source-map-explorer.
Install:
npm install -g source-map-explorer
Usage:
source-map-explorer bundle.min.js
source-map-explorer bundle.min.js bundle.min.js.map
source-map-explorer bundle.min.js*
source-map-explorer *.js
This will open up a visualization of how space is used in your minified bundle.
I created bundlejs for this exact reason. Bundlejs was designed to be a fast and always accessible online bundler that can treeshake, analyze the bundle, minify, gzip & brotli the bundle, give the compressed size, and also return the fully bundled code, you can check it out at https://bundlejs.com.
The source code is available on GitHub at https://github.com/okikio/bundlejs
However, if you're goal is to just check what the npm install size for packages, I highly recommend https://packagephobia.com. I didn't create packagephobia but it's a high quality tool that covers the other niche when it comes to checking js package sizes