How do I package a node module for BuckleScript / ReasonML?

Question

Background

I'm an absolute beginner in BuckleScript, and while I've downloaded packgages with npm before, I've never written a library.

Goal: installing my new package local package in my project using npm

I am trying to wrap some parts of the service worker api in JavaScript. I have started with a file bs-service-worker/src/ExtendableEvent.re like so

type _extendableEvent('a);
type extendableEvent_like('a) = Dom.event_like(_extendableEvent('a));
type extendableEvent = extendableEvent_like(Dom._baseClass);

[@bs.send] external waitUntil: (extendableEvent, Js.Promise.t('a)) => unit
    = "waitUntil";

This compiles and produces ExtendableEvent.bs.js as expected.

Now, though, I'd like to go ahead and test what I have so far by creating a new npm project and importing what I have locally. I created a new sibling directory and did an npm install ../bs-service-worker. That succeeded, and then I did a sanity-check build on my new BuckleScript project. That also succeeded.

The issue: opening my module causes an error

When I add open ExtendableEvent; to Demo.re in the new project, I get the following error:

  We've found a bug for you!
  /home/el/workbench/bucklescript/bs-service-worker-examples/src/Demo.re 11:6-20

   9 │  
  10 │ /**/  
  11 │ open ExtendableEvent;  
  12 │   
  13 │ /*  

  The module or file ExtendableEvent can't be found.
  - If it's a third-party dependency:  
    - Did you list it in bsconfig.json?  
    - Did you run `bsb` instead of `bsb -make-world`  
      (latter builds third-parties)?  
  - Did you include the file's directory in bsconfig.json?  

What I've tried

• I'm guessing I'm misusing BuckleScript here instead of npm because npm is so widely adopted and well documented that I think I'd have found the problem, but I'm definitely not ruling out the possibility that I'm misusing npm, too.
• I do have "bs-service-worker" listed as a bs-dependency. I also tried "../bs-service-worker" in case BuckleScript didn't like the virtual directory, but it didn't seem to help.
• My npm run build command is indeed npx bsb -make-world.

More code:

bs-service-worker/bs-config.json

{
  "name": "bs-service-worker",
  "version": "0.1.0",
  "sources": {
    "dir" : "src",
      "subdirs" : true,
      "public": "all"
  },
  "package-specs": {
    "module": "commonjs",
    "in-source": true
  },
  "suffix": ".bs.js",
  "bs-dependencies": [

  ],
  "warnings": {
    "error" : "+101"
  },
  "namespace": true,
  "refmt": 3
}

bs-service-worker-examples/bsconfig.json

{
    "name": "bs-service-worker-examples",
    "version": "0.1.0",
    "sources": {
      "dir" : "src",
      "subdirs" : true
    },
    "package-specs": {
        "module": "commonjs",
        "in-source": true
    },
    "suffix": ".bs.js",
    "bs-dependencies": [
        "bs-service-worker",
        "bs-fetch", 

    ],
    "warnings": {
        "error" : "+101"
    },
    "namespace": true,
    "refmt": 3
}

bs-service-worker-examples/package.json

{
  "name": "bs-service-worker-examples",
  "version": "0.0.1",
  "scripts": {
    "build": "npx bsb -make-world",
    "start": "npx bsb -make-world -w",
    "clean": "npx bsb -clean-world"
  },
  "keywords": [
    "BuckleScript"
  ],
  "author": "Eleanor (https://webbureaucrat.bitbucket.io)",
  "license": "MIT",
  "devDependencies": {
    "bs-platform": "^7.3.2"
  },
  "dependencies": {
    "bs-fetch": "^0.6.1",
    "bs-service-worker": "file:../bs-service-worker"
  }
}

Easy Reproduction of the Issue

The fastest way to reproduce this would be to fork this repository and try to add it as a local npm dependency.

Answer 1

The problem seems to be that you have "namespace": true in your library's bsconfig.json, which will wrap all the modules in a namespace module with a silly generated name based on the name field. In this case it will be BsServiceWorker I think.

You could just remove that setting, or set it to false, but namespacing is a good idea to avoid collisions between modules from different libraries, or your own app, so I would recommend setting it to a custom, sensible name. For example:

"namespace": "ServiceWorker"

You can then open ExtendableEvent in the consumer project with:

open ServiceWorker.ExtendableEvent;

For more details, see the documentation on the namespace field.