question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Bump and pin dependencies per-release

See original GitHub issue

Codes under work well some times before, but never worknow : try { autobahn = require('autobahn'); } catch (e) { console.log("wamp_orbital.js.connectServer exception = " +e); return; } Exception occurs:

wamp_orbital.js.connectServer exception = TypeError [ERR_NO_ICU]: “fatal” option is not supported on Node.js compiled without ICU

Since I didn’t meet such errors before, and I didn’t change any code, maybe there is some difference in node-version or Electron-version, but I forgot corrent ones.

node -v v12.10.0 electron 2.0.8

Anyone met the same problem as me?

Issue Analytics

  • State:open
  • Created 4 years ago
  • Comments:8 (2 by maintainers)

github_iconTop GitHub Comments

1reaction
peterforgacscommented, Dec 6, 2019

Thanks, this works with electron >= 4.0.0 but produces the same error on older electron versions.

In this case, this is caused by the cbor dependency increased the minimum required Node.js version in its latest stable version, which older electrons do not support.

This would not be a problem in itself, they follow semver. The problem is that autobahn only sets a minimum version requirement in the package.json. (>=)

This causes all clients to install the latest stable version of the dependency. And there is no guarantee that the latest stable version of the dependency Node.js requirement is in line with the specific electron Node.js version.

As a possible long term solution:

Can we fixate the concrete versions for the dependencies? Instead of cbor >= 3.0.0 cbor 3.0.0 etc. ( Same holds true for other dependencies )

This would make autobahn much more stable in electron in the long run.

Created a test repo to illustrate the problem here.

You can change the electron version and see how it behaves differently.

0reactions
oberstetcommented, Dec 6, 2019

Sounds great!

alright, then we’ll do that. changing issue label to enhancement …

Electron changed its versioning system about a year ago. … Changing the major version of big electron application requires quite lot of work.

thanks for explaining! understood & agreed

Read more comments on GitHub >

github_iconTop Results From Across the Web

How should you pin dependencies and why? – The Guild
Historically the most common way to pin dependencies was to specify an exact version in your package. json , for example using the...
Read more >
3.14.x: Prerelease publish failed to bump `version` in most ...
When looking for cycles, collaps them to a single node. In the Edit 3 of 3.14. · CD and B are both leaf...
Read more >
Versions of dependencies - Yarn
When you want to specify a dependency you specify its name and a version range in your ... Versions can also have pre-release...
Read more >
Should you Pin your JavaScript Dependencies?
The pros and cons of dependency pinning for JavaScript/npm. ... If instead you "pin" your dependencies rather than use ranges, it means you...
Read more >
NuGet Package Version Reference - Microsoft Learn
NuGet 4.3.0+ supports SemVer 2.0.0, which supports pre-release numbers ... Any of the package's dependency version ranges has a minimum or ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found