{'fraction_non_alphanumeric': 0.014154281670205236, 'fraction_numerical': 0.0, 'mean_word_length': 5.256637168141593, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
JavaScript module system: exploring the design space

While JavaScript is one of the most widely used programming languages not only for web applications but also for large projects, it does not provide a language-level module system. JavaScript developers have used the module pattern to avoid name conflicts by themselves, but the prevalent uses of multiple libraries and even multiple versions of a single library in one application complicate maintenance of namespace. The next release of the JavaScript language specification will support a module system, but the module proposal in prose does not clearly describe its semantics. Several tools attempt to support the new features in the next release of JavaScript by translating them into the current JavaScript, but their module semantics do not faithfully implement the proposal. In this paper, we identify some of the design issues in the JavaScript module system. We describe ambiguous or undefined semantics of the module system with concrete examples, show how the existing tools support them in a crude way, and discuss reasonable choices for the design issues. We specify the formal semantics of the module system, which provides unambiguous description of the design choices, and we provide its implementation as a source-to-source transformation from JavaScript with modules to the plain JavaScript that the current JavaScript engines can evaluate.