pnpm support

[pelhamrj]

Oneschema uses eventemitter3 rather than the built-in EventEmitter. Due to this, when using pnpm as the package manager, which requires strict dependency resolution, eventemitter3 is never installed and thus code doesn't compile. Specifically, the error received is OneSchemaImporterClass.on() is not a function. This is resolved by bringing in eventemitter3 as a dependency in my local project.

This isn't an issue when yarn legacy since yarn hoists dependencies automatically. Will pnpm be supported?

[behnam-oneschema]

Thanks, @pelhamrj, for reporting this.

Oneschema uses eventemitter3 rather than the built-in EventEmitter.

True. I believe we can now switch to use the native browser classes for this. (https://developer.mozilla.org/en-US/docs/Web/API/EventTarget probably.)

---

Due to this, when using pnpm as the package manager, which requires strict dependency resolution, eventemitter3 is never installed and thus code doesn't compile.

I'm not too familiar with pnpm. Could you please elaborate on why "strict dependency resolution" does not work with this explicit direct dep declaration?

sdk/packages/importer/package.json

Lines 34 to 35 in 60246fb

	"dependencies": {
	"eventemitter3": "^4.0.7",

---

Specifically, the error received is OneSchemaImporterClass.on() is not a function. This is resolved by bringing in eventemitter3 as a dependency in my local project.

To be honest, I think it's strange that the build system is not catching the failing import and it's only at runtime that you would see a failing inherited property on the object. Are you sure it is a dependency resolution issue? Based on this behavior, I'm guessing it's something else.

---

Will pnpm be supported?

We don't actively test with pnpm, but bug reports are appreciated and we will work on fixes.

[pelhamrj]

Thank you so much for responding!

True. I believe we can now switch to use the native browser classes for this. (https://developer.mozilla.org/en-US/docs/Web/API/EventTarget probably.)

This would solve the problem overall!

I'm not too familiar with pnpm. Could you please elaborate on why "strict dependency resolution" does not work with this explicit direct dep declaration?

pnpm doesn't install peer dependencies by default and uses a flattened structure. It will install these with additional configurations or the use of the --shamefully-hoist flag, but by default pnpm expects more explicit package declarations.

To be honest, I think it's strange that the build system is not catching the failing import and it's only at runtime that you would see a failing inherited property on the object. Are you sure it is a dependency resolution issue? Based on this behavior, I'm guessing it's something else.

It is in fact caught at build, not at runtime. We've been using the importer for about a year without issue. This issue specifically occurred when deleting node_modules and our yarn lock file and reinstalling with pnpm. Suddenly we couldn't build anymore until we explicitly installed eventemitter3.

When using legacy yarn (which hoists automatically) the resolution is fine. When switching to pnpm, we fail here. We chose pnpm as our new package manager (since legacy yarn is deprecated) as it seems to have overtaken yarn as the community favorite thus having better community support, has smaller impacts on disk space as it uses a central package store and hard linking for projects rather than installing duplicates everywhere on your disk, and because of that store is much faster at installation of subsequent projects.

We don't actively test with pnpm, but bug reports are appreciated and we will work on fixes.

Really appreciate you responding, and on a Saturday at that!

[behnam-oneschema]

This would solve the problem overall!

:)

pnpm doesn't install peer dependencies by default and uses a flattened structure. It will install these with additional configurations or the use of the --shamefully-hoist flag, but by default pnpm expects more explicit package declarations.

Hum... something doesn't add up, though. We don't use "peer" dependencies in our packages, but only regular production dependencies.

Package @oneschema/react has:

  "dependencies": {
    "@oneschema/importer": "^0.7.0",
    "tslib": "^2.x"
  },

And package @oneschema/importer has:

  "dependencies": {
    "eventemitter3": "^4.0.7",
    "tslib": "^2.x"
  },

And you can see that eventemitter3 package is not imported from @oneschema/react.

So, these are all direct explicit dependencies without any undeclared relationships.

It is in fact caught at build, not at runtime. We've been using the importer for about a year without issue. This issue specifically occurred when deleting node_modules and our yarn lock file and reinstalling with pnpm. Suddenly we couldn't build anymore until we explicitly installed eventemitter3.

I see. I'm baffled, though, why pnpm doesn't work with our dependency declarations.

Are you sure @oneschema/react is added to your regular production deps list?

Really appreciate you responding, and on a Saturday at that!

Of course, @pelhamrj! :) Let's see how we can resolve this, since it's important that you folks can install and use these packages without complications.

[pelhamrj]

Thanks again! You’re absolutely right, your dependencies are declared properly, and this isn’t a peer dependency issue. We actually do not use @oneschema/react, we're using @oneschema/importer natively. Per the documentation, we installed just @oneschema/importer.

By default, pnpm is strictly content-addressable and isolates each package’s dependencies unless explicitly hoisted. This means:

• @oneschema/importer will have its own internal node_modules with eventemitter3
• Because our code is importing something from @oneschema/importer that uses eventemitter3 directly, the bundler tries to resolve eventemitter3 relative to our app — not inside @oneschema/importer. This is due to pnpm's flattened node_modules structure.

So our error is due to transitive imports leaking into our build, and pnpm correctly saying, “I don’t know what this is unless you install it.”

This is a nuance of pnpm’s strict module isolation. Since our build references a class that extends eventemitter3, pnpm expects it to be resolvable from the root. yarn and npm hoist this automatically, but pnpm does not. We resolved this by installing eventemitter3 directly.

This may not be an explicit fix on your end, unless of course you remove the dependency and use the native implementation. It may simply be a note to add to documentation for pnpm users.

[behnam-oneschema]

Thanks for sharing more details, @pelhamrj.

If understand your set up correctly:

1. You do NOT have any import ... from "eventemitter3". Meaning, your code is NOT trying to access eventemitter3 library.
2. However, yes, the runtime of @oneschema/importer does use eventemitter3—which is kind of the main and only point of production dependencies. Whether this is a function call or subclassing, it is a valid cross-library access which is expected to be understood by the build system, to load the referenced item/object accordingly.

So, I think you might have faced rare bug in pnpm which needs to be fixed in pnpm, or worked around in your system. I would suggest reporting it upstream with them.

If you think there's any other adjustment in our package/build settings that can improve your experience, I would be happy to look into it. However, removing eventemitter3 as a dependency, that probably would take a while as it will require extensive tests.

[pelhamrj]

Hi,

1. Yes, that is correct.
2. This is understood.

This isn't a problem with pnpm. This is a known constraint of pnpm, it requires explicit declarations of packages and doesn't rely on transitive dependencies. Since the importer extends EventEmitter from eventemitter3, it requires that to be declared. This is no different than some other packages, for example @apollo/client which relies on graphql as well as @mui/material which relies on @emotion/react and @emotion/styled.

The difference here though is that these packages explain in the documentation that when installing, we need to also include these transitive dependencies.

If EventEmitter was encapsulated and extended internally only, it should work, however since it is directly extended, and pnpm doesn't allow for transitive dependencies, it requires it to be declared in the package.json of the consuming library. This is because upon build, when it tries to use the OneSchemaImporterClass it also tries to pull in EventEmitter from that third party library, which simply doesn't exist since it isn't hoisted up by pnpm. Again, this isn't a bug on their side, nor really on yours, I think the crux of the matter is the documentation.

I totally understand it may take time to remove eventemitter3, and I'm certainly not asking you do so, was just curious if it'd be worth adding this to your documentation that eventemitter3 should also be installed with @oneschema/importer similarly to how other libraries manage their dependencies as outlined above.

No big deal either way, this is more of a heads up (especially for others who may stumble here when using pnpm). I will inform my peers accordingly and we'll have an internal communication that outlines that we need to install the transitive dependency explicitly. I really appreciate your time in looking into this!