node-pre-gyp
module-alias
node-pre-gyp | module-alias | |
---|---|---|
3 | 2 | |
1,097 | 1,717 | |
-0.1% | - | |
1.9 | 1.5 | |
10 days ago | 27 days ago | |
JavaScript | JavaScript | |
BSD 3-clause "New" or "Revised" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
node-pre-gyp
-
Has anyone got sqlite3 and electron working on Apple M1?
The problem is that it determines the the system's platform and architecture using the binary compiling package node-pre-gyp and this very savior of a Github issue details how node-pre-gyp is not handling ARM architecture detection properly and basically mixing everything up. Because it's not detecting properly, even if we build our own binding with --build-from-source when installing, it still won't work because it is compiling the wrong binding file for the wrong architecture. To make matters worse, if we don't use --build-from-source, it just simply fetches the Intel precompiled binding file. napi-v6-darwin-unknown-x64
-
Getting Rid of Dust / 1.0.0-beta.4
Indeed, Snowboy uses node-pre-gyp which helps to publish and install Node.js C++ addons from binaries. So when a new Node.js version is shipped, node-pre-gyp must update its listing of the supported targets by specifying the:
-
Mac Mini M1 issues with Node JS < 15
Node is like 95% OK with ARM chips, so you might have a tricky dependency. Every time I had problems it was related to something depending on node-pre-gyp, there is an issue about it .
module-alias
-
Getting Rid of Dust / 1.0.0-beta.4
But here is the thing, I want to continue to use the module-alias npm package as I find it brings better readability of the imports. I found that it requires to build a custom module loader to resolve it. I concluded that it was too much steps to achieve for a small output, then I chose to postpone the Babel dropping task. If you are interested into that specific case, there is an ongoing GitHub issue.
-
UIengine project setup
module-alias
What are some alternatives?
patch-package - Fix broken node modules instantly 🏃🏽♀️💨
Nodemon.io - Monitor for any changes in your node.js application and automatically restart the server - perfect for development
gitpod - The developer platform for on-demand cloud development environments to create software faster and more securely.
fastify - Fast and low overhead web framework, for Node.js
nan - Native Abstractions for Node.js
Express - Fast, unopinionated, minimalist web framework for node.
Electron - :electron: Build cross-platform desktop apps with JavaScript, HTML, and CSS
browserify - browser-side require() the node.js way
opn - Open stuff like URLs, files, executables. Cross-platform.
npm-run-all - A CLI tool to run multiple npm-scripts in parallel or sequential.
webworker-threads - Lightweight Web Worker API implementation with native threads
parcel-resolver-ts-base-url - Resolve tsconfig baseUrl and paths imports with Parcel