I am a new to TypeScript and a bit confused. If my version of TypeScript is 1.0.1 (say I'm stuck on VS2012), how do I use tsd to find type definitions for a library that given I require tsc 1.0.1.
Without version information, I will often get type definitions for tsc1.4.
I figure there must be a way to do this in tsd, but I have not been able to figure it out.
Cheers!
how do I use tsd to find type definitions for a library that given I require tsc 1.0.1
You can't easily. You need to run tsd install somedefinitionyoucareabout -soa and then change the git sha saved in tsd.json to some thing that is from the 1.x branch: https://github.com/borisyankov/DefinitelyTyped/tree/1.0.1
That said you really should consider updating to TypeScript latest.
If you are trying to download TypeScript type definitions for an older version of TypeScript with tsd, you may do the following.
If you look inside tsd.json you will see the key "ref", which is set to "master".
{
"version": "v4",
"repo": "borisyankov/DefinitelyTyped",
"ref": "master",
...
}
This refers to the master branch of borisyankov/DefinitelyTyped.
There are other branches of borisyankov/DefinitelyTyped such as 1.0.1 which target previous releases of TypeScript.
Simply modify tsd.json to point to another branch, and it will retrieve type definitions specific to that version of TypeScript.
{
"version": "v4",
"repo": "borisyankov/DefinitelyTyped",
"ref": "1.0.1",
...
}
After you have done this, you can install a type definition with --save and inspect the commit hash in tsd.son to confirm.
Related
I did Google about this but no luck.
Basically, I need a particular version of a NPM package (A) to be installed if the local Node.js version is X, if not then install version B of that NPM package. This needs to be a part of build process, so its all dynamic.
If there was a way to have this config in package.json, then it would have been a straightforward solution for me.
How do I achieve this?
You can achieve this by using Yarn as your dependency management tool in combination with the Selective Versions Resolutions feature.
More specifically in your case you'd use it as described in the "Mapping version specifications" format, based on that your package.json you would include something like the following, assuming that version X=1.0.3 and version B=2.0.0 in the following example:
"devDependencies": {
"a": "1.0.3"
},
"resolutions": {
"a#==1.0.3": "a#2.0.0"
}
I have a project that uses Typescript, using the newer #types/foo style of installing typings packages.
When my build server installs all npm modules, sometimes I get a complete failure when compiling the typescript as some dependent definitions are no longer matching up.
For instance, I now have a problem with #types/gulp. In its package.json, dependencies are listed as:
"dependencies": {
"#types/node": "*",
"#types/orchestrator": "*",
"#types/vinyl": "*"
},
But now #types/orchestrator has updated, and it now breaks the version of #types/gulp that I have defined in my apps package.json.
How am I supposed to lock down version of dependencies like this so I no longer get this problem, or is there another workaround?
Unfortunately, I suddenly get these issues which sets development back by hours trying to sort it out. This makes using Typescript in a fast moving environment difficult.
How am I supposed to lock down version of dependencies like this so I no longer get this problem
Run npm shrinkwrap or just specify an exact version:
"#types/vinyl": "6.3.12"
If my package has these dependencies
{ "name": "my-package",
"dependencies": { "foobar":"~1.0.3", "baz":"2.0.9" }
And the foobar package has these dependencies
{ "name": "foobar",
"dependencies": { "baz":"^2.0.0" }
and the most recently released version of baz is 2.1.0, the first run of yarn will install baz#2.1.0 in foobar/node_modules.
How do I force yarn to use the baz#2.0.9 package for foobar?
My understanding is that this would be possible using npm shrinkwrap (a la this question).
The summary of my question probably is: Yarn creates repeatable, deterministic installations, but how do I customize that installation?
If you do in fact have a sub-dependency that is overly restrictive in what versions it will accept, you can override them using yarn.
UPDATED EDIT: Yarn now, as of 1.0, officially supports the "resolutions" block. So the way to override resolutions is to just add a block like this to package.json:
"resolutions": {
"package-a": "2.0.0",
"package-b": "5.0.0",
"package-c": "1.5.2"
}
You'll get warnings for "incompatible" versions sometimes, but I find that some packages (like socket.io) are overly restrictive in what version they accept, and so I'll happily select the latest version when it doesn't actually break things.
Original but outdated answer below.
It sounds like the original question wasn't exactly correct, but the original question was in fact the one I wanted answered, and I found an answer, so here it is for posterity:
I'm using the socket.io library, and it has component-emitter as a dependency. But it has a pair of versions that it requires. This is what the yarn.lock file looked like before I changed anything:
component-emitter#1.1.2:
version "1.1.2"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.1.2.tgz#296594f2753daa63996d2af08d15a95116c9aec3"
component-emitter#1.2.0:
version "1.2.0"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.0.tgz#ccd113a86388d06482d03de3fc7df98526ba8efe"
So it was including two copies of the component emitter in my client code. I looked, and there didn't appear to be any breaking changes between 1.1.2 and 1.2.0 (or 1.2.1, which was current). I first tried just changing the yarn.lock file:
component-emitter#1.2.1, component-emitter#^1.2.1, component-emitter#1.1.2:
version "1.2.1"
resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.1.tgz#137918d6d78283f7df7a6b7c5a63e140e69425e6"
This worked, but the file has warnings about it being autogenerated, meaning that every single update or new package I add will stomp on this change. A bit of searching found the yarn --flat option, which will force yarn to choose no more than one of each package in the entire project. That seems like overkill to me, since I'm sure there are actual cases of incompatibility between older and newer packages. I just wanted to eliminate a redundant package from my client code, to make the download smaller; I still want the development packages to all work correctly.
But in the docs to yarn --flat I found a reference to a "resolutions" block that can go in package.json:
"resolutions": {
"package-a": "2.0.0",
"package-b": "5.0.0",
"package-c": "1.5.2"
}
So I tried putting "component-emitter" : "1.2.1" in a new "resolutions" block in my package.json, and it in fact flattened component-emitter to 1.2.1 for all places that required it, and now I have only one copy in my client code.
(And now the resolutions block is completely supported in yarn, so you don't even need to use --flat.)
This is now possible with yarn's selective version resolution feature.
In your project's package.json, use resolutions:
"resolutions": {
"foobar/**/baz": "2.0.9"
}
This overrides package foobar's (and any other packages under it) version of baz, forcing it to be version 2.0.9.
EDIT: This is now deprecated, please read this answer instead:
https://stackoverflow.com/a/46615878/2398593
#SomeCallMeTime's answer is great and we've been doing that for month at work.
Unfortunately, this is not possible anymore since the v0.24.x (see that comment).
There's an opened PR on Github with an RFC proposal to have a simple way of handling that use case without having to keep an eye on the generated lockfile.
I am searching for a way to break the build, if a user is using a different node.js version as defined in the project.
Ideally to put some checks in grunt or bower or npm to stop, if a certain npm/node version is not used to run the current build.
Even though engineStrict is deprecated, you can still accomplish this behavior without needing to use an additional script to enforce a Node version in your project.
Add the engines property to your package.json file. For example:
{
"name": "example",
"version": "1.0.0",
"engines": {
"node": ">=14.0.0"
}
}
Create a .npmrc file in your project at the same level as your package.json.
In the newly created .npmrc file, add engine-strict=true.
engine-strict=true
This will enforce the engines you've defined when the user runs npm install. I've created a simple example on GitHub for your reference.
You can use the "engineStrict" property in your package.json
Check the docs for more information: https://docs.npmjs.com/files/package.json
Update on 23rd June 2019
"engineStrict" property is removed in npm 3.0.0.
Reference : https://docs.npmjs.com/files/package.json#enginestrict
"engineStrict" has been removed and "engines" only works for dependencies. If you want to check Node's runtime version this can work for you:
You call this function in your server side code. It uses a regex to check Node's runtime version using eremzeit's response It will throw an error if it's not using the appropriate version:
const checkNodeVersion = version => {
const versionRegex = new RegExp(`^${version}\\..*`);
const versionCorrect = process.versions.node.match(versionRegex);
if (!versionCorrect) {
throw Error(
`Running on wrong Nodejs version. Please upgrade the node runtime to version ${version}`
);
}
};
usage:
checkNodeVersion(8)
You can use the engines property in the package.json file
For example, if you want to make sure that you have a minimum of node.js version 6.9 and a maximum of 6.10, then you can specify the following
package.json
{
"name": "Foo",
....
"engines": {
"node": ">=6.9 <=6.10"
}
}
If you want to enforce a specific version of npm, you might use:
https://github.com/hansl/npm-enforce-version
If you want to enforce a version of node when executing you can read the version of node that is currently running by checking against:
process.versions
For more info: https://nodejs.org/api/process.html#process_process_versions
I have a module and I'd like to let the user decide which version he wants to use, the purely written in javascript or the native written in C (so he needs to compile it first).
The npm install command doesn't have any option but you can choose the version so I can create two branches: v1.x for the js and v2.x for the native.
If the user wants to install the module written in javascript:
"dependencies": {
"my-module": "1.x"
}
If the user wants to install the native module:
"dependencies": {
"my-module": "2.x"
}
Are there other better ways to publish the purely and native modules with the same module name?
OK, that's not exactly what you are looking for, but here goes…
You are trying to find an NPM equivalent to Gentoo Use Flags, which doesn't exist. The closest thing you could do it publish your pure-JS version and have users directly link to the git repo instead if they want to use the native version.
In package.json:
"dependencies": {
"mymodule": "1.2.3" // js version
}
"dependencies": {
"mymodule": "http://github.com/mymodule-native" // native version
}
You users won't have to change their require to switch between versions, only a single line in package.json.
Another solution would be to attempt to build the native version without raising an error if it fails. Then you can have a simple setting in your module to switch between implementations. You can have a look at this other stackoverflow thread.