Skip to content

Which RegEdit library to use #1

@TheJaredWilcurt

Description

@TheJaredWilcurt

The current set of libraries for interacting with the registry have some limitations:

  • windows-registry
    • 🤷 Depends on ffi at runtime, which may cause issues with webpack-ing.
    • 😃 Has a decent sized API. It could be simplified a little more, but most of the hard work is done.
    • 😔 Requires Visual Studio 2015, Visual C++ Build Tools or Visual Studio 2017. Also requires Python 2.7. Also requires node-gyp. Node version must match version in NW.js.
      • I think the only way around this would be to call reg.exe directly, which could conflict with Group Policy rules.
    • 😍 Written in JS and has tests in place
    • 😞 Doesn't seem to be merging in PRs any more.
    • 😞 Doesn't seem to be compatible with Node 12+ (according to PR's, have not tested yet)
  • native-reg
    • 🤮 Written in TerperScrips and C++
    • 🤷 Uses NAPI for a Node "in process native module", not sure what the pros/cons of this are
    • 😨 Seems to try to be a one-for-one wrapper around the Windows Registry API, which is pretty nasty looking, and thus the library's API, though not as bad, is still pretty gnarly.
    • 😍 Maintainer has said he is willing to take help on designing a better API
    • 🤮 "Documentation" requires reading the source code (TS 🤮) and comparing against Microsoft's documentation (🤮).
    • 👍 This may be the most complete option though
    • 😌 Maintainer seems helpful.
  • node-winreg
    • 😕 Depends on reg.exe which breaks as soon as you enable "Prevent access to registry editing tools" Group Policy rules (including QUERY operations). More details.
  • registry-js
    • 🤷 Supposedly faster than reg.exe, though who cares?
    • 😒 Literally only has 1 item in the API (to read a list). Which requires a lot of boilerplating to handle response.
    • 😒 Cannot create or destroy keys.
    • 😒 Maintainers are not working on it but "will review PRs".
    • 🤮 Code is written in C++ and TerperScrips (why call this registrty-js then?)
    • 😩 Requires custom build for Electron, so may not be easily compatible with NW.js.
    • 😡 Was built by GitHub Desktop team, which may have bias against NW.js (as seen by previous GitHub developers refusing to make minor code changes in projects to support both Electron and NW.js. GitHub is ironically the worst at open source. Similar to Facebook's approach of "build it for us, you can use it too, but we won't merge your PR's if they don't benefit us, make your own library").
    • 😔 Requires Visual Studio 2015, Visual C++ Build Tools or Visual Studio 2017. Also requires Python 2.7. Also requires node-gyp. Node version must match version in NW.js.
  • Write my own custom approach using something like invoking PowerShell.
    • 🤷 This would be slow, but I don't really care about performance.
    • 😢 Would become its own project which may take even longer to build than this one
    • 😪 Would require a lot more research and more intimate knowledge of the registry and how to interact with it.
    • 😨 Ultimately may have similar group policy restrictions, would be difficult and painful to test for this if there isn't clear documented guidance around this online.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions