Adam Stone-Lord
4c11731ee1
* Revert "chore: simplify build script (#27547)" This reverts commit0a86ec686e. * Revert "chore: upgrade lerna to 6, cache build step (#26913)" This reverts commit9e60aeba8f. * [run ci] * chore: upgrade lerna to 6, cache build step (#26913) * chore: update build-npm-modules script * chore: update build-npm-modules script * chore: update build-npm-modules script * chore: update build-npm-modules script * chore: update lerna to 6 * [run ci] * try caching build step * we can't clean without building after * add dependencies on scripts for npm packages * update commands * add config for data-context build step * fix output configurations for npm packages, add gitignores * revert changes to config and data-context build steps * fix outputs * run with cache * fix outputs for cli * actually fix outputs * test with cache --------- Co-authored-by: astone123 <adams@cypress.io> * chore: simplify build script (#27547) * chore: simplify build script * update CI workflows * fix workflows * empty commit because Percy weirdness * chore: add driver, reporter, config as implicit dependencies for runner package (#27559) * run all workflows on branch * chore: parallelize test-binary-against-recipes CI step (#27570) * chore: fix some easy circular dependencies in dep graph (#27612) * chore: remove gulp tasks from postinstall (#27616) * empty commit * chore: minor improvements to node_modules_install (#27647) * chore: fix cypress:open and dev scripts * run with cache [run ci] * exclude mochaawesome assets from .yarnclean [run ci] * bump cache again [run ci] * run cached [run ci] * chore: do not cache cli build step [run ci] * update workflow command and docs for build-cli [run ci] * fix commands that use scope [run ci] * use different branch for publish repo [run ci] * percy weirdness? [run ci] * fix postbuild cli script [run ci] * try to remove typescript from production binary [run ci] * fix circular dependency [run ci] * try removing ts from node_modules [run ci] * remove typescript resolution [run ci] * remove redundant target scripts * update to lerna scoped commands * remove unneeded yarn in lerna command * try to fix Electron install in Windows workflow --------- Co-authored-by: Jordan <jordan@jpdesigning.com> Co-authored-by: Dave Kasper <dave.m.kasper@gmail.com>
@packages/v8-snapshot-require
Tool to load a snapshot for Electron applications that was created by @tooling/v8-snapshot.
Table of Contents
Features
@packages/v8-snapshot-require provides modules snapshotted by @tooling/v8-snapshot to @packages/packherd-require
and helps in locating modules to load from the snapshot by deriving their keys from information about each
module provided by packherd.
Loading From Snapshot
In order to facilitate loading from the snapshot, @packages/v8-snapshot-require ties into the
@packages/packherd-require resolution mechanism in order to help it obtain the key to locate
a fully initialized module exports or its definition from the snapshotted Object that
@packages/v8-snapshot-require also provides during @packages/packherd-require initialization
inside the snapshot-require setup.
It uses the resolver-map in order to resolve modules without querying the file system.
Once v8-snapshot provides this key to packherd it then tries to first load a fully initialized version of the module, aka exports, falling back to a function which will initialize it, aka definitions and only finally loads it from the file system via Node.js.
Most of that logic lives inside @packages/packherd-require and it is recommended to read its
documentation.
Resolver Map
The resolver map is constructed from metadata that as esbuild-snap produces as a side effect of bundling the application's dependencies and optionally the app's modules.
The keys of this map are the directory relative to the project base dir, from which a module
was resolved, concatenated with the import request string (separated by '***') and the value
the fully resolved path relative to the project base dir.
This map is embedded into the snapshot and used fast module key resolution and used to resolve a module's key via the getModuleKey function.
Examples
In order to learn how to orchestrate snapshot creation and loading please have a look at the examples provided with this app, for instance:
Debugging and Diagnosing
In order to gain insight into how the modules are loaded please set the
DEBUG=(cypress:pack|cypress:snap)* which will cause the tool to emit a wealth of
information part of which will provide insight into how many modules were initialized
from the snapshot and which weren't.
cypress:packherd:debug { exportHits: 20, definitionHits: 8, misses: 3 }
It will also provide information about what it encountered inside the snapshot, namely the number of:
exportsmodules that are fully initialized inside the snapshotdefinitionsfunctions that will returnmodule.exportswhen invoked
NOTE: that definitions and exports overlap as a module's definition is always included even
if its export is included as well.
Thus the below means that we have 12 modules that are included fully initialized and 6 (18 - 12) that aren't.
exports: 12
definitions: 18