Socket
Socket
Sign inDemoInstall

es-module-lexer

Package Overview
Dependencies
0
Maintainers
1
Versions
67
Alerts
File Explorer

Advanced tools

Install Socket

Detect and block malicious and high-risk dependencies

Install

    es-module-lexer

Lexes ES modules returning their import/export metadata


Version published
Weekly downloads
20M
decreased by-2.25%
Maintainers
1
Install size
26.5 kB
Created
Weekly downloads
 

Package description

What is es-module-lexer?

The es-module-lexer package is designed to perform lexical analysis of JavaScript modules to identify import and export statements. It is particularly useful for tools that need to analyze or transform ES module syntax, such as bundlers, compilers, and code analysis tools.

What are es-module-lexer's main functionalities?

Lexical Analysis

This feature allows you to perform lexical analysis on a string containing ES module source code. The `parse` function returns two arrays: one for the import statements and one for the export statements found in the source code.

import { init, parse } from 'es-module-lexer';

(async () => {
  await init;
  const source = `import { a } from 'module-a';`;
  const [imports, exports] = parse(source);
  console.log(imports);
  console.log(exports);
})();

Other packages similar to es-module-lexer

Readme

Source

ES Module Lexer

A JS module syntax lexer used in es-module-shims.

A very small single JS file (4KiB gzipped) that includes inlined Web Assembly to very fast source analysis for ES modules only.

Outputs the list of exports and locations of import specifiers, including dynamic import and import meta handling.

Comprehensively handles the JS language grammar while remaining small and fast - can parse 2MB of JavaScript in under 30ms from a completely cold start, and in just 20ms after a few runs, see benchmarks for more info.

Usage

npm install es-module-lexer
import { init, parse } from 'es-module-lexer';

// Wait for WebAssembly to load. Alternatively use parse asynchronously.
await init();

// Note: Parsing error messages thrown are not user friendly
//       and only provide stack information in the lexer itself.
//       It is recommended to always catch and fall back to an alternative
//       parser for proper error output.

const source = `
  import { a } from 'asdf';
  export var p = 5;
  export function q () {

  };

  // Comments provided to demonstrate edge cases
  import /*comment!*/ ('asdf');
  import /*comment!*/.meta.asdf;
`;

try {
  var [imports, exports] = parse(source);  
}
catch (e) {
  console.log('Parsing failure');
}

// Returns "asdf"
source.substring(imports[0].s, imports[0].e);

// Returns "p,q"
exports.toString();

// Dynamic imports are indicated by imports[1].d > -1
// In this case the "d" index is the start of the dynamic import
// Returns true
imports[1].d > -1;

// Returns "'asdf'"
source.substring(imports[1].s, imports[1].e);
// Returns "import /*comment!*/ ("
source.substring(imports[1].d, imports[1].s);

// import.meta is indicated by imports[2].d === -2
// Returns true
imports[2].d === -2;
// Returns "import /*comment!*/.meta"
source.substring(imports[2].s, imports[2].e);

Benchmarks

Benchmarks can be run with npm run bench.

Current results:

Module load time
> 6ms
Cold Run, All Samples
test/samples/*.js (2150 KiB)
> 29ms

Warm Runs (average of 25 runs)
test/samples/d3.js (491 KiB)
> 5.6ms
test/samples/d3.min.js (274 KiB)
> 3.44ms
test/samples/magic-string.js (34 KiB)
> 0.36ms
test/samples/magic-string.min.js (20 KiB)
> 0.04ms
test/samples/rollup.js (902 KiB)
> 9.24ms
test/samples/rollup.min.js (429 KiB)
> 5.24ms

Warm Runs, All Samples (average of 25 runs)
test/samples/*.js (2150 KiB)
> 24.8ms

Building

To build download the WASI SDK from https://github.com/CraneStation/wasi-sdk/releases.

The Makefile assumes that the clang in PATH corresponds to LLVM 8 (provided by WASI SDK as well, or a standard clang 8 install can be used as well), and that ../wasi-sdk-6 contains the SDK as extracted above, which is important to locate the WASI sysroot.

The build through the Makefile is then run via make lib/lexer.wasm, which can also be triggered via npm run build-wasm to create dist/lexer.js.

On Windows it may be preferable to use the Linux subsystem.

After the Web Assembly build, the CJS build can be triggered via npm run build.

Limitations

The lexing approach is designed to deal with the full language grammar including RegEx / division operator ambiguity through backtracking and paren / brace tracking.

The only limitation to the reduced parser is that the "exports" list may not correctly gather all export identifiers in the following edge cases:

// Only "a" is detected as an export, "q" isn't
export var a = 'asdf', q = z;

// "b" is not detected as an export
export var { a: b } = asdf;

The above cases are handled gracefully in that the lexer will keep going fine, it will just not properly detect the export names above.

License

MIT

FAQs

Last updated on 21 Aug 2019

Did you know?

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts

SocketSocket SOC 2 Logo

Product

  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.


  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc