How to get the version of a remote npm package using a bin script - npm

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.

Related

Use different versions of the same package in dev or prod?

(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).

How to make each Vue build include a version accessible in Vue app?

In Vue, I'd like to be able to get the current build version. Preferably, it would be in YYYY-MM-DD-HH-MM format (the build time), rather than a random hash (which would be ok too).
Here's how someone did this
https://medium.com/#howitson/passing-generated-build-numbers-to-vue-app-f301e6b11877
Another idea:
have a bash script which updates .env file with a line VUE_APP_BUILD_VERSION=... (is there any utility for this?)
and then run npm run build
Any suggestions for simpler ways? Maybe get the .js file path and use that? /js/app.5e716dd8.js
You can use npm version patch in your build script, and get the version number from package.json.

Peer dependency that is also dev dependency of linked npm module is acting as a separate instance

In my app, I have these dependencies:
TypeORM
typeorm-linq-repository AS A LOCAL INSTALL ("typeorm-linq-repository": "file:../../../IRCraziestTaxi/typeorm-linq-repository"), who has a dev dependency AND a peer dependency of TypeORM
The reason I use a "file:" installation of typeorm-linq-repository is that I am the developer and test changes in this app prior to pushing releases to npm.
I was previously using node ~6.10 (npm ~4), so when I used the "file:" installation, it just copied the published files over, which is what I want.
However, after upgrading to node 8.11.3 (npm 5.6.0), it now links the folder rather than copying the published files.
Note, if it matters, that my environment is Windows.
The problem is this: since both my app and the linked typeorm-linq-repository have TypeORM in their own node_modules folders, TypeORM is being treated as a separate "instance" of the module in each app.
Therefore, after creating a connection in the main app, when the code that accesses the connection in typeorm-linq-repository is reached, it throws an error of Connection "default" was not found..
I have searched tirelessly for a solution to this. I have tried --preserve-symlinks, but that does not work.
The only way for me to make this work right now is to manually create the folder in my app's node_modules and copy applicable files over, which is a huge pain.
How can I either tell npm to NOT symlink the "file:" installation or get it to use the same instance of the TypeORM module?
I made it work pretty easily, although I feel like it's kind of a band-aid. I will post the answer here to help anybody else who may be having this issue, but if anybody has a more proper solution, feel free to answer and I will accept.
The trick was to link my app's installation of TypeORM to the TypeORM folder in my other linked dependency's node_modules folder.
...,
"typeorm": "file:../../../IRCraziestTaxi/typeorm-linq-repository/node_modules/typeorm",
"typeorm-linq-repository": "file:../../../IRCraziestTaxi/typeorm-linq-repository",
...

What is the recommended way to update project.pbxproj file for the app while upgrading react-native version

I am using rn-diff to upgrade react-native version for my app. Sometimes, the project.pbxproj is updated to contain some new dependencies or updates to the existing dependencies. What is the recommended way to update this file? I don't think that I can just copy and paste the changes shown in the diff because it may create some duplicates or create some conflicting entries in the file.
For example, below link contains changes made to the project.pbxproj file while changing from version 0.54.4 to 0.55.0. There are a lot changes to the project.pbxproj file and I am not sure if I am supposed to copy them over or I should rather be updating some dependencies myself in Xcode.
https://github.com/ncuillery/rn-diff/compare/rn-0.54.4...rn-0.55.0
In such cases I'm usually sad that I need to do this terrible thing ;)
But being serious: sadly going through RN Diff is like the very best thing that you can do now (unless you have NOT detached Expo.io but then you wouldn't probably ask here). So basically you go through each change that happened between your version and version to which you want to update and copy paste the changes in these files. As rarely you can apply patches (because your project file will be so different that there is no way that it will work out correctly).
My way of doing it is:
- see what changed
- see code block next to it, that is somehow easy to find out in my code (like some block of code that has unique ID + few properties around e.g. can be some native modules that are always there like TEXT or View or whatever, something which is always in RN)
- find the same element in my code and paste the new code above / below that code that was the same
Rinse and repeat
Please take a look at Upgrading to new React Native versions for upgrading your react native version!
Also if you want to update all of your dependencies, you can:
npm i -g npm-check-updates
ncu -u
npm install
And there is a library called npm-check-updates which:
Find newer versions of package dependencies than what your package.json or bower.json allows!

New project with GULP

I made a project using GULP and I downloaded several modules with the NPM cmd. For a new project, should I copy/paste my old project with the files "gulpfile.js", "package.json" and the folder "node_module" or i have to redownload all the modules ? I tried to copy/paste and it worked perfectly, but maybe there is an another way to do it (like download each module with one command line) ?
Thank you !
Copying your old package.json file into your new project is perfectly reasonable when you also use a copy of your existing gulpfile.
Now, instead of copying your node_module folder just run npm install. It does exactly the same thing as copying and pasting but with the added bonus of checking package versions, deprecated dependencies, and so on...
Quick tip: If you ever run into problems as I have deleting/removing packages given that theirs paths might be longer than what the OS allows use the tool rimraf. Install it globally and then you can call rimraf on anything. CAUTION! this tool will erase everything no questions asked