Both are real, supported ways to ship PeerJS - they are just two different build formats for two different workflows, and the errors you hit come from mixing them up. You can confirm all of this from the package's own build config (package.json targets plus the lib/global.ts / lib/exports.ts sources on the repo).

The npm package = ES/CJS modules for a bundler.
package.json points its module / main / types fields at dist/bundler.mjs, dist/bundler.cjs and dist/types.d.ts, all built from lib/exports.ts. That file has the real named exports (Peer, PeerError, and type-only exports like DataConnection, MediaConnection, PeerOptions, etc.). This is what makes import { Peer, DataConnection } from "peerjs" and the intellisense work. The catch: "peerjs" is a bare specifier, and browsers cannot resolve bare specifiers on their own - something has to map peerjs to a file and pull in its dependency tree (eventemitter3, @msgpack/msgpack, webrtc-adapter, ...). That "something" is a bundler. This is what the getting-started guide quietly assumes.

The standalone peerjs.js / peerjs.min.js = a global IIFE build for a plain <script> tag.
Those are the files cdnjs/libman gives you. In package.json their targets (browser-minified / browser-unminified) are "outputFormat": "global" and their source is lib/global.ts, which is literally just:

(window as any).peerjs = { Peer, util };
(window as any).Peer = Peer; // deprecated

So this file is not an ES module and exports nothing - it only assigns to window as a side effect. That is exactly why import { Peer } from "./peerjs.libman/peerjs" gives you ts2306 ("not a module") / ts2304 ("Cannot find name 'Peer'"). And it is why your "hack" import "/lib/peerjs/peerjs.js"; works: a specifier with no bindings is a side-effect import, so it just runs the file, which sets window.Peer - after that you are using the global Peer, not an imported one. (You will notice lib/global.ts is even listed under "sideEffects" in package.json.) It is meant to be used like this, with no import at all:

<script src="/lib/peerjs/peerjs.min.js"></script>
<script>
  const peer = new Peer("pick-an-id");
</script>

So which should you use?

• If you have (or do not mind adding) a bundler - Vite, webpack, esbuild, Rollup, Parcel - use the npm package and keep writing import { Peer, DataConnection } from "peerjs" in your .ts. The bundler resolves the bare peerjs import from node_modules, inlines the dependency tree, and the browser only ever sees the final bundle. You get the types/intellisense for free. This is the intended path and, given you are already writing TypeScript with import syntax, the one I would pick.

• If you specifically want no build step, use the standalone peerjs.min.js via a <script> tag and just use the global Peer - do not try to import from it. To still get type checking, keep peerjs installed as a devDependency and pull types only, e.g. import type { DataConnection } from "peerjs"; while Peer comes from the global. (One nuance: the type-only export means DataConnection cannot be imported as a runtime value regardless of approach - it is a type.)

One thing I would avoid: an import map pointed at that cdnjs peerjs.min.js. Since that file is the global build with no ES exports, a bare import { Peer } from "peerjs" still will not get named bindings from it. If you want browser-native import with no bundler, point an import map at an ESM CDN build (e.g. esm.sh) instead of the cdnjs global file.

Short version: nothing is strictly "required" - npm plus a bundler gives you importable modules and types, the standalone JS gives you a window.Peer global for script tags, and the ts2306/ts2304 errors were just from trying to import named exports out of the global-format file.