Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runtime output tarball is structured incorrectly #192

Open
sgammon opened this issue Jul 27, 2023 · 0 comments
Open

Runtime output tarball is structured incorrectly #192

sgammon opened this issue Jul 27, 2023 · 0 comments
Assignees
Labels
bug Something isn't working tool:esbuild Issues and features relating to `esbuild` support

Comments

@sgammon
Copy link
Member

sgammon commented Jul 27, 2023

Currently, the runtime package expects to find a directory within the JS modules tarball, at the name __runtime__; however, the runtime codebase produces a structure under the directory node_modules. There are some other bugs, too, which are worth fixing, so that the JS modules can be used directly as an output in the main codebase. These are summarized below.

1) Directory structure

  • Expected: __runtime__/<module>/...
  • Actual: node_modules/<module>/...

We need to restructure the tarball so that it matches the expected layout. Without this layout, loading the tarball will immediately crash the CLI upon start.

2) Compression of tarball

Currently, the tarball is a simple, uncompressed package. It needs to be compressed or the CLI will fail to load it.

3) Incorrect module pointers

Via built-in module package.json files, certain built-in module files have a module or main attribute which points to an invalid file. Obviously this must be fixed as it also causes crashes. We need to uniformly provide main and module for all built-in modules, and additionally provide the exports property.

The package.json structure should look like this (sample from buffer):

{
  "name": "buffer",
  "main": "buffer.cjs",
  "module": "buffer.mjs",
  "exports": {
    ".": {
      "require": "./buffer.cjs",
      "import": "./buffer.mjs"
    }
  }
}

4) Uniform availability of both ESM and CJS exports

As mentioned in part above, all built-in modules should provide both types of import support -- CJS and ESM. This is probably accomplished via tuning the esbuild flags for those modules.

Example (again, from buffer):

buffer.cjs:

/**
 * Intrinsic: Buffer.
 *
 * Provides a shim which offers a `Buffer` implementation that is compatible with Node.js-style imports.
 */

/**
 * Export the intrinsic `Buffer` type as the main export, and also an export called `Buffer`.
 */
module.exports.Buffer = globalThis['Buffer'];

buffer.mjs:

/**
 * Intrinsic: Buffer.
 *
 * Provides a shim which offers a `Buffer` implementation that is compatible with Node.js-style imports.
 */

/**
 * Export the intrinsic `Buffer` type as the main export, and also an export called `Buffer`.
 */
export const Buffer = globalThis['Buffer'];

export default {
    Buffer
};

5) Invalid ESM bundles

There is a bug coming from somewhere which results in an invalid ESM package within the builtin JS modules. It generally looks like this:

export {
  <...> as default
}
@sgammon sgammon added bug Something isn't working tool:esbuild Issues and features relating to `esbuild` support labels Jul 27, 2023
@sgammon sgammon self-assigned this Jul 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working tool:esbuild Issues and features relating to `esbuild` support
Projects
Status: No status
Development

No branches or pull requests

1 participant