Erroneous builds, parcelRequire, and manifestations of a bundling problem

[StoneCypher]

Hiya.

Something's weirdly wrong with your build. I don't use parcel, so I don't know exactly what, but.

It appears that Parcel has an internal implementation of require called parcelRequire which isn't being put into your build, or is being put into your build in a way that isn't visible in all places, or perhaps is expected to be provided downstream.

You see a variety of strange manifestations of this when your users are using other bundlers:

• Unable to import Peer 1.0.1 in Angular 8 app  #552 Unable to import Peer 1.0.1 in Angular 8 app
• 'parcelRequire is not defined' When used with snowpack. #753 'parcelRequire is not defined' When used with snowpack.
• peerjs_min is not a constructor error when initialising Peer #761 peerjs_min is not a constructor error when initialising Peer

I hit this myself. Here is a near-minimal build using rollup. Unfortuantely, you're looking through minified code. To find the correct location (line 21 column 890,) either copy pasta into a code editor, or search for parcelRequire=f,i)throw i;return f}({"EgBh"). The revealed selection starts (ie, parcelRequire=) at the throw.

I believe that this is either a timing or a scope visibility bug, on grounds that several people believe they are solving it by making a global with the correct name, at which point the throw goes away (ostensibly because it's now pointing at some irrelevant variable,) only to be replaced by a complaint that the needed constructor or some needed method doesn't exist on said throwaway.

jmonster suggests that the issue is merely the missing declaration of the outer scoped variable, and jlalmes provides a shim on the window object by matching name, which falls into scope through globality rules, but which would break on node.

It seems that this is expositional - in #761 the user is able to self-service by dealing with the scoped instance on the window global. Whatever the problem is is resolved by the time that member is bound.

Either way, parcel shouldn't be building. If it's a missing outer scope variable it should reject, and if it's being pushed before it's ready it should be being deferred.

∴ I believe your parcel configuration to be damaged.

It's worth noting that there's a possibly-related issue:

• ability to require peerjs inside the node repl #677 ability to require peerjs inside the node repl

Strictly speaking this isn't related. However I would have expected a library like peerjs to be available to node, and right now it's requiring the window global, which is node-antithetical. If you expect parcel to be testing for that, or packing in a shim or a sham, it's not currently doing so.

[pankerit]

same error

[canotur]

It is living error. Is there anyone can find a solution that?

[afrokick]

@StoneCypher Thank you for the detailed issue.

In the next version we'll include esm/cjs files, so it'll suite for all cases.

NodeJS support already exists in beta. You can try it via npm i peerjs@beta

[StoneCypher]

I'm not interested in node. I just want this to work in a regular build.

Does the cjs build still have access to browser primitives?

How far out is 2?

Are you aware of anyone having this working in a regular build? This blocked me for a nine months. I went to a competitor

[jonasgloning]

Thank you for your detailed report, @StoneCypher. Parcel@1 had some long-standing bugs that weren’t fixed because the engineering capacity was bound for version 2.

It was the same for PeerJS: Creating a possible version 2 delayed fixes for version 1. Also our two main maintainers hadn’t had much time for personal reasons. That changed; we now got two maintainers working on PeerJS and are prioritizing version 1. We are back on track.

All bundling issues should be fixed from version v1.4.

Node support is coming but is not high on the priority list. Node does not support WebRTC natively, and its polyfill wrtc has some issues and has not seen a commit in two years.