I'm trying to compile a Salesforce sfdx plugin which is a node project with (among others) the following dependency chain that ultimately leads to fake-timers#^7.1.0:
#salesforce/command#2.2.0 -> #oclif/test#^1.2.4 -> fancy-test#^1.4.3 -> #types/sinon#* -> #sinonjs/fake-timers#^7.1.0.
When compiling it with the Typescript compiler tsc, I get the following error:
node_modules/#sinonjs/fake-timers/types/fake-timers-src.d.ts:11:28 - error TS2304: Cannot find name 'queueMicrotask'.
11 queueMicrotask: typeof queueMicrotask;
~~~~~~~~~~~~~~
Found 1 error.
error Command failed with exit code 1.
This looks like a bug in fake-timers-src.d.ts but introduced in 7.1.0 so I could try to lock the version at 7.0.5 but that might break all kinds of other things.
Does anybody who uses/maintains fake-timers know how to fix this? Or will this be fixed in a future version?
BTW I'm a total NodeJS n00b so if there's something really obvious here that I'm missing, please be kind and just tell me what it is :)
Thanks!
Frans
Frans! fatso83 from the Sinon team here :)
The problem here has all to do with TypeScript and nothing to do with Node, so I feel your pain. No wonder you are wondering. The problem is that the definitions are probably missing that property. For version 7 we tried to generate TypeScript definitions from JSDoc. This works reasonably well for simpler type, but ultimately, TypeScript is more powerful in describing types than JSDoc (like the typeof operator), so it was an uphill battle that would never result in the same quality as the types available from the external Definitely Typed project. We ended up abandoning that effort and therefore this will not be fixed, but it will naturally go away with version 8 (that will not be shipping its own types).
What you can do is this: npm install #sinonjs/fake-timers#6 (which is the previous version) and npm install #types/sinonjs__fake-timers#6 (which are the externally maintained types).
You might find some background for this in this issue.
Related
I am working on a project under NodeJS that uses ES6 imports/exports (hence having set type: module in its package.json) and want to automate some tasks using Grunt. Now, I absolutely love grunt, but it appears to me that even in 2022 it is still not able to work nicely with ES6 modules? I always get an error saying "require() of ES Module /vagrant/Gruntfile.js from /vagrant/node_modules/grunt/lib/grunt/task.js not supported."
I understand where this is coming from, and I do understand there are workaround options - in particular, renaming Gruntfile.js to Gruntfile.cjs and passing it to grunt with the --gruntfile command line option. But that is incredibly annoying - it makes the command six times as long as it would be if I could just run grunt and be done with it. Pretty much the same goes for transpiling with something like Babel: That is exactly the kind of thing grunt is intended to handle in the first place, so it feels a bit like the horse riding the jockey. I feel like this should "just work".
Am I missing something here, or is grunt really unable to handle ES6 imports out of the box?
Actually, looking at the grunt github page it appears that a recent commit has addressed it.
I guess this issue will therefore be resolved in their next update.
I'm trying to fix this problem for 6 hours now and I'm slowly starting to lose my mind, so please excuse my generic question.
First of all I am using:
Node: 8.10.0 | npm: 5.6.0 | Yarn: 1.5.1
I just upgraded my project to Node v8 and npm refused to install all dependencies, so i installed yarn which fixed the issue immediately.
My sources are compiled using Laravel Mix which utilises Webpack, Babel, ... internally.
Installing and compiling of my sources works perfectly fine now but for some reason my compiled js file is not working anymore (even if I downgrade to the previous Node version - 6.10.0).
Uncaught TypeError: fn.bind is not a function
at nativeBind (admin.js?id=8c4a6887899977ba8021:72515)
at initMethods (admin.js?id=8c4a6887899977ba8021:75849)
at initState (admin.js?id=8c4a6887899977ba8021:75617)
at Vue._init (admin.js?id=8c4a6887899977ba8021:76936)
at new Vue (admin.js?id=8c4a6887899977ba8021:77037)
at Object../resources/assets/js/admin.js (admin.js?id=8c4a6887899977ba8021:83350)
at __webpack_require__ (admin.js?id=8c4a6887899977ba8021:20)
at Object.1 (admin.js?id=8c4a6887899977ba8021:83790)
at __webpack_require__ (admin.js?id=8c4a6887899977ba8021:20)
at ./node_modules/babel-loader/lib/index.js?{"cacheDirectory":true,"presets":[["env",{"modules":false,"targets":{"browsers":["> 2%"],"uglify":true}}]],"plugins":["transform-object-rest-spread",["transform-runtime",{"polyfill":false,"helpers":false}]]}!./node_modules/vue-loader/lib/selector.js?type=script&index=0!./resources/assets/js/components/Autocomplete.vue.Object.defineProperty.value (admin.js?id=8c4a6887899977ba8021:63)
I have aboslutely no ideas what this error means let alone what causes it.
I know that the error message is pretty generic and could probably mean a lot of things but hopefully someone knows what it means given my context.
Thanks!
#Ortomala Lokni's answer pushed me in the right direction.
For some reason I thought my problem was related to my build scripts, npm, webpack or anything of that sort, which - of course - it was not.
Event though it wasn't really an API change as he suggested there was simply a wrong call to the VueJS constructor in my JS file which, for some reason, had been ignored by a previous release of VueJs but apparently not by the current one.
For anyone experiencing some weird bugs that just don't make sense I recommend the following:
First of all: Determine what really is your problem - if it compiles it is most certainly not related to your JS build
Comment out all of your JS code in your main file
The error should be gone at this point
Narrow down the error by trying to uncomment line by line (or block by block) and test your code after each uncomment
Even though this steps might seem obvious you can easily forget about such simple thing because of the million things that could possibly break when working with modern JS.
Sometime when you upgrade libraries you have to adapt some code. As Javascript is not a typed language, the problem does't appears at compile time but at run time.
In your case, I suppose that you have a problem similar as this one.
Check which libraries yarn has upgraded and verify if some API has changed.
Will somebody please help me understand how to update typings via the typings.json?
When I update certain libraries, their typings become deprecated. This is all well and good, but running typings install --save or any combination of typings install with any of my given libraries throws errors a-la "unable to find angular-protractor", etc.
The problem is that I can't understand how you're supposed to derive the version number. I understand that it is derived from the timestamp of the commit or whatever, but that seems like a terrible way to try to update something as simple as a typing. Particularly since, the only way I've found to be able to upgrade them, is find them and update typings.json manually.
For example:
{
"globalDependencies": {
"angular-protractor": "registry:dt/angular-protractor#1.5.0+20160425143459",
}
}
So, version 1.5.0+20160425143459 is deprecated, but I have no idea what the new one is since it won't tell me, and the angular-protractor definition on github in the definitely typed repo doesn't seem to provide any info past the major/minor/patch.
I'm sure I'm missing something simple. Thanks for any help.
I have been working with TypeScript off and on for two years now. I am not an expert by any means, but I've spent some time in the eco-system: with VS2015 and node tools, with VSCode, and at the command line with tsc and typings (also used by VSCode).
And I have struggled with the correct way to get static typing and auto-complete etc in the code I've been writing.
I have a repo I maintain (EasyNodeQ) which was the start of my TypeScript experience and I sort of got that to a manageable place with ///reference and DefinitelyTyped. But any time I tried to use that within another project I had issues.
Things got a little better when I started using typings (rather than downloading the *.d.ts files myself) and especially with the ambient flag.
But I still have lots of issues trying to use that package within other projects. Depending on the approach I take, I get lots of Duplicate Identifier's, or module not found's or...
And this can range from Node definitions, to packages I use in both places (like node-uuid).
All I want to understand is this: how to I structure EasyNodeQ so that as I'm working on it, I get the static typings benefits of TypeScript but also have it be seamlessly included in other projects which can then also get these benefits?
Does that make sense?
The basic use cases are: npm install a package and get its typings, use my EasyNodeQ package and get its typings, work in a new project that uses EasyNodeQ and other packages and easily manage those typings.
Preferably in a VSCode or command line way...
This is with ES6 and the latest version of TypeScript (though an answer that works with ES5 would be nice - just not required).
I hope this makes sense. I've looked all over and I can't cobble together an answer that works.
UPDATE
I'm not convinced I've done this the "right" way, but it's working now so I thought I'd post the various things I've done (generally in the order I think they mattered and not inclusive because I may have forgotten some).
I hadn't npm'd the dependency package (easynodeq) and was just using a git url in the package.json - so I created a proper npm package and now install that package from npm
Instead of trying to use Bus.ts as both code and definition, I made Bus.js the "meat" of the npm, and built a Bus.d.ts file (also in the npm)
Embraced typings, using non-ambient definitions where possible and a mix of ambient definitions downloaded (via git) from DefinitelyTyped and "--ambient" definitions for the rest (because I'm still confused about the difference). The ambient definitions ended-up being the majority: node, express, serve-static, express-serve-static-core, mime, amqplib, when vs just bluebird and node-uuid, even though most of them were found by "typings search ..." Am I doing something wrong?
Modified package.json to also do "typings install"
Cleaned-up the git repo
There are several ways to make this work today. As you mentioned, using Typings works for definitions that aren't natively included in their NPM packages. For ones that do, you can using the typings field in package.json and it'll work with node module resolution. When you combine this together, you can publish packages that use both typings.json and relies on packaged typings - though this now forces your consumers to be using Typings to install the definitions. None of this, however, works with "ambient" definitions as they can not be namespaced properly.
This may be useful: https://github.com/typings/typings/blob/master/docs/faq.md#should-i-use-the-typings-field-in-packagejson. There's also dozens of examples I have using both workflows: https://github.com/blakeembrey/change-case/blob/master/package.json#L6 which uses node module resolution all the way down and https://github.com/blakeembrey/popsicle/blob/master/typings.json which uses Typings instead. Using Typings is only possible because it works to create namespaced ambient modules for you, but they won't conflict.
I tried to build the example package from here but sadly I get following error:
error: Couldn't find package std in any of the workspaces in the RUST_PATH (C:\U
sers\User\Desktop\test\hello.rust:C:\Users\User\Desktop\test\hello:C:\Users\Use
r.rust)
Now it's kinda obvious that there is some issue with RUST_PATH but I am somewhat unable to find documentation concerning it.
note: I'm using Windows 8 64 bit and Rust 0.8
Rustpkg has been removed from basic library and moved into librustpkg.
There are alternatives like Makefile or CMake, but I assume the preferred version it's using cargo-lite.
My advice is just look at Rust-CI for a project that uses package manager you like most and copy it's build shamelessly.
UPDATE: A new package manager for rust has been announced. It's called Cargo. We'll see how it works out, but that is possible future default.
Rustpkg has been removed from Rust. Hopefully we will get something to replace it.