npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

qsharp-lang

v1.23.1-dev

Published

qsharp language package for quantum development

Readme

qsharp npm module

This package contains the qsharp compiler and language service functionality shipped for consumption via npm.

The source is written in TypeScript, which is compiled to ECMAScript modules in the ./dist directory. The wasm binaries from the Rust builds are copied to the ./lib directory.

Consuming browser projects should import from this module and use a bundler to create their own JavaScript bundle, and also copy the wasm file to their project and provide the URL to it when calling the loadWasmModule method so it may be located and loaded.

Node and browser support

wasm-bindgen generates different files for the browser and Node.js environments. The wasm is slightly different, and the loader code is quite different. This can be seen in ./lib/web/qsc_wasm.cjs and ./lib/nodejs/qsc_wasm.js files respectively. Specifically, the web environment loads the wasm file using async web APIs such as fetch with a URI, and Node.js uses require to load the fs module and calls to readFileSync. Once the wasm module is loaded however, the exported APIs are used in a similar manner.

To support using this npm package from both environments, the package uses "conditional exports" https://nodejs.org/dist/latest-v18.x/docs/api/packages.html#conditional-exports to expose one entry point for Node.js, and another for browsers. The distinct entry points uses their respective loader to load the wasm module for the platform, and then expose functionality that uses the loaded module via common code.

When bundling for the web, bundlers such as esbuild will automatically use the default entry point, whereas when loaded as a Node.js module, it will use the "node" entry point.

Note that TypeScript seems to add the ['import', 'types', 'node'] conditions by default when searching the Node.js exports, and so will always find the 'node' export before the 'default' export. To resolve this, a 'browser' condition was added (which is same as 'default' but earlier than 'node') and the tsconfig compiler option "customConditions": ["browser"] should be added (requires TypeScript 5.0 or later). esbuild also adds the 'browser' condition when bundling for the browser (see https://esbuild.github.io/api/#how-conditions-work).

Design

This package provides two services, the compiler and the language service.

The API for using these services is similar whether using a browser or Node.js, and whether running in the main thread or a worker thread. You instantiate the service and call operations on it which complete in the order called.

All operations return a Promise which resolves then the operation is complete. Some operations may also emit events, such as debug messages or state dumps as they are processed. The service itself can also emit events which can be subscribed to using addEventListener.

See the Q# playground code at https://github.com/microsoft/qsharp/tree/main/source/playground for an example of code that uses this package. The unit tests at https://github.com/microsoft/qsharp/tree/main/source/npm/test are also a good reference.

Promises, Events, and Cancellation are based on JavaScript or Web standards, or the VS Code API:

The standard Web APIs for custom events were added to Node.js in v16.17. https://nodejs.org/dist/v16.17.0/docs/api/events.html, but behind an experimental flag. As CustomEvent is not on the global by default until v19 or later, the code will use Event with a 'detail' property manually set until v20 is in common use.

The VS Code implementation for cancellation tokens is viewable in their source code at <src/vs/base/common/cancellation.ts>. This code uses a simplified version of that API.

Testing

Node.js tests can be run via node --test (see https://nodejs.org/dist/latest-v18.x/docs/api/test.html#test-runner-execution-model).