fix: #63

[NguyenDuck]

Correct type declaration in package.json

[rlandav]

Thanks! One piece of feedback.

[lucyydotp]

Hi, hope you don't mind me chiming in here. We've just run into #63 at Noxcrew.

Unlike many teams, we don't bundle our scripts in most situations in order to preserve stack traces and keep output code readable and debuggable without needing to faff with source maps. This obviously means that we need to package dependencies ourselves, which we do by through a node_modules-style copy of every package in the scripts folder, and some generated shims to make exports work nicely.

Which brings me onto my question - would this make more sense as just a simple main and types combo? Using node's exports field feels counterintuitive to me, as it's not something that Minecraft itself supports, meaning that import resolution has to be done ahead-of-time by an external tool (i.e. a bundler, or in our case, a ts transformer plugin). Using exports makes that process considerably more complicated, especially so when a package has conditional exports like this one does, despite being ESM-only.

[rlandav]

Hi, hope you don't mind me chiming in here. We've just run into #63 at Noxcrew.

Unlike many teams, we don't bundle our scripts in most situations in order to preserve stack traces and keep output code readable and debuggable without needing to faff with source maps. This obviously means that we need to package dependencies ourselves, which we do by through a node_modules-style copy of every package in the scripts folder, and some generated shims to make exports work nicely.

Which brings me onto my question - would this make more sense as just a simple main and types combo? Using node's exports field feels counterintuitive to me, as it's not something that Minecraft itself supports, meaning that import resolution has to be done ahead-of-time by an external tool (i.e. a bundler, or in our case, a ts transformer plugin). Using exports makes that process considerably more complicated, especially so when a package has conditional exports like this one does, despite being ESM-only.

So the main rationale for using exports is really just about using the newest standard for defining package entry points (per documentation here). At the end of the day, whether we use main or exports, it is tied to a specific implementation detail of node during local dev, because the module resolution is all relative file based once it's loaded from a behavior pack (and more constrained in general). Minecraft doesn't reason about package.json files.

Which I guess gets to your question. This package, as well as the rest of scripting libraries, tend to operate under an assumption of being used within some sort of JS build tooling, with a very slight preference to usages based on our ts-starter, but that mostly boils down to general tools like TS and an assumption that bundling will happen if you are taking a dependency on NPM packages like @minecraft/math. However, on each version release, we also include a zip file that contains a pre-bundled version of math + types for scenarios where bundling is not used, that you can just drop into whatever workflow you have, and could just be plopped into a behavior pack and referenced by path.

It sounds like where this currently breaks down in your use case is in creating the import shim?

Thanks for this feedback btw @lucyydotp !

[lucyydotp]

After giving this some more thought, you're absolutely right - ultimately it's an npm package which means it follows node conventions. I've reworked how our compiler tooling works to transform imports, replicating node's resolution behaviour, instead of creating shims (the goal is for my tooling to work with any platform-agnostic npm package and these things may well appear in other packages). Ignore me!