Package Exports
- ipjs
This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (ipjs) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.
Readme
Universal JavaScript Build and Packaging
This is a toolchain for the next phase of JavaScript development. It enables developers to write JavaScript modules in ESM that work universally across many environments (Node.js import, Node.js require, Browser, Deno, etc).
You start by just writing a standard ESM module. You'll need to include
"type": "module" in your package.json, as well as a "main" entry
point or an export map.
npx ipjs buildThis will build a package in the dist directory that has different
versions of your files compiled for different environments and a
new package.json file that exposes all of these files to the correct
Node.js and compiler entry points.
That's it ;)
You can also compile your tests.
npx ipjs build --testsNote: You'll need to use "named self imports", import mymodule from "mymodule",
in your tests so that we can compile different CJS versions of those tests for
Node.js and the browser.
You can publish to by either running npm publish in the dist directory or using:
npx ipjs publishRequirements
There's a few Node.js and ESM features you need to stick to using and a few you need to avoid. Some are because there just isn't a very good way to provide consistent representations and some are because we need some more explicit information about your library in order to detect the dependency tree and built it successfully.
Only use named exports in files in the package.json exports map
If you use default exports from files in the exports map:
- CJS/JSDoc+Typescript users of your module will find that
tscfails to compile as it expects a the.defaultproperty to be present on anythingrequired from your module - If they switch to
.defaultto satisfytsc, node will resolve cjs at runtime via the"require":entry from the exports map which does not have a.defaultso will fail - If they switch back to no
.default, running bundled cjs in the browser will also fail as it will be supplied the esm version where.defaultis present after all