Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.26%. Comparing base (04f210d) to head (8c997c5).
⚠️ Report is 1 commits behind head on master.

@@           Coverage Diff           @@
##           master    #1446   +/-   ##
=======================================
  Coverage   92.26%   92.26%           
=======================================
  Files          32       32           
  Lines        5781     5781           
=======================================
  Hits         5334     5334           
  Misses        447      447           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

This might already be fixed in #1436, just not published to npm.

Interesting - anyone care to describe the difference between those two solutions?

We should probably put out another release once import gets merged and we've kicked the tires a bit.

@tonious You're right, the current master branch already works just fine. I didn't notice before.

Interesting - anyone care to describe the difference between those two solutions?

If I understand correctly, there are two manifoldCAD.d.ts files in the manifold-3d package:

1. manifold-3d/dist/manifoldCAD.d.ts This one is correctly bundled/built by rollup, doesn't have any strange "internal" type imports.
2. manifold-3d/lib/manifoldCAD.d.ts This one is generated by tsc and has references to other type files that are not exported by the package.

Because of the order of the exports in package.json, when running tsc on a script that imports manifold-3d/manifoldCAD, number 2 was being hit before number 1.
tsc then encounters the "internal" (not exported) type files such as manifold-encapsulated-types.d.ts, and fails to generate types correctly.

@tonious If there is no other good reason to export these manifold-encapsulated-types.d.ts and manifold-global-types.d.ts files from the package, then I am happy to close this PR in favor of your other changes.

API-Extractor rolls up the type declarations. I've disabled a bunch of the functionality, as this is pretty much all we need it to do. There are separate roll-ups for overall manifoldCAD functions, and the few functions like animation and level-of-detail that are only changeable at the top level.

@Loosetooth said:

@tonious If there is no other good reason to export these manifold-encapsulated-types.d.ts and manifold-global-types.d.ts files from the package, then I am happy to close this PR in favor of your other changes.

Now that I've thought about it a little, this PR makes sense. I didn't feel comfortable entirely omitting the not-rolled-up-version of ./lib/manifoldCAD.d.ts, but hadn't really thought about why. Not everyone is going to use the entire manifoldCAD part of manifold. Still, one should be able to reasonably use part of it, which means that the varying ./lib/*.d.ts files should load cleanly. They can't all be rolled up as that would result in duplicate type definitions.

Can I request a few small changes while you're cleaning up my mess?

Complete extensions for consistency:

  "./manifold-encapsulated-types.d.ts": "./manifold-encapsulated-types.d.ts",
  "./manifold-global-types.d.ts": "./manifold-global-types.d.ts"

Also, we should probably explicitly export manifold.(js|d.ts), even though it's under main and types in package.json already.

  "./manifold.js": "./manifold.js",
  "./manifold.d.ts": "./manifold.d.ts",
  "./manifold": {
    "import": {
      "types": "./manifold.d.ts",
      "default": "./manifold.js"
    }
  },

@elalish said:

We should probably put out another release once import gets merged and we've kicked the tires a bit.

I'm working on it! 😂

@tonious I added your proposed changes.

I also added and explicit export for manifoldCAD.js.

Looks good! Thanks, @Loosetooth :)