Security News
The Dark Side of Open Source
At Node Congress, Socket CEO Feross Aboukhadijeh uncovers the darker aspects of open source, where applications that rely heavily on third-party dependencies can be exploited in supply chain attacks.
interpret
Advanced tools
Package description
The interpret npm package is designed to be a dictionary of require extensions and associated file extensions. It allows developers to automatically register the appropriate require extension for files based on their file extensions. This is particularly useful when working with different types of files that need to be required in Node.js applications, such as .coffee, .ts, or .jsx files.
Registering require extensions
This code retrieves the require extension for TypeScript files, allowing Node.js to understand how to process and import .ts files.
require('interpret').extensions['.ts']
Associating file extensions with custom handlers
This code demonstrates how to associate a custom file extension (.custom) with a custom compiler or handler to be used when requiring files with that extension.
var interpret = require('interpret');
var extensions = interpret.extensions;
extensions['.custom'] = require('my-custom-compiler');
Rechoir is a package that allows you to automatically register the appropriate require hooks based on a file's extension. It is similar to interpret but goes a step further by actually attempting to require the necessary module to handle the file extension.
Liftoff is a CLI framework that builds on top of interpret. It enables applications to specify which interpreters they support for configuration files, and it will automatically require the necessary dependencies.
This package is used to hook into the require function to add support for transpiling files on the fly. It is similar to interpret in that it deals with require extensions, but it focuses more on the runtime aspect of transpiling or processing files.
Readme
A dictionary of file extensions and associated module loaders.
This is used by Liftoff to automatically require dependencies for configuration files, and by rechoir for registering module loaders.
Consumers should use the exported extensions
or jsVariants
object to determine which module should be loaded for a given extension. If a matching extension is found, consumers should do the following:
module
property. If successful, the register
property (a function) should be called with the module passed as the first argument. Advanced: An optional second argument can be provided to replace the default configuration for a hook.This module provides two top-level properties: extensions
and jsVariants
.
Note: This module does not depend on any of the loaders it recommends; instead, end-users are expected to install the hooks they want to use for the file types they want to use. See supported extensions and their hooks in the sections below.
extensions
A mapping of file extensions to modules which provide a require.extensions loader.
File extension keys are all in the format of '.foo'
or '.foo.bar'
and module loader values are either null
if the loader should fallthrough to node's loader,
or a string representing the module to be required, an object of { module: 'foobar', register: function }
, or an array containing those strings and/or objects.
A sample of an entry containing multiple hooks would look like:
{
'.ts': [
'ts-node/register',
'sucrase/register/ts',
{
module: '@babel/register',
register: function(hook) {
hook({
extensions: '.ts',
rootMode: 'upward-optional',
ignore: [ignoreNonBabelAndNodeModules],
});
},
},
],
}
Supported extensions and their hooks
.babel.js:
- '@babel/register'
.babel.jsx:
- '@babel/register'
.babel.ts:
- '@babel/register'
.babel.tsx:
- '@babel/register'
.cjs:
- interpret/cjs-stub
.coffee:
- coffeescript/register
.coffee.md:
- coffeescript/register
.cts:
- ts-node/register
.esbuild.js:
- esbuild-register/dist/node
.esbuild.jsx:
- esbuild-register/dist/node
.esbuild.ts:
- esbuild-register/dist/node
.esbuild.tsx:
- esbuild-register/dist/node
.esm.js:
- esm
.js:
- built-in node.js loader
.json:
- built-in node.js loader
.json5:
- json5/lib/register
.jsx:
- '@babel/register'
- sucrase/register/jsx
.litcoffee:
- coffeescript/register
.mdx:
- '@mdx-js/register'
.mjs:
- interpret/mjs-stub
.node:
- built-in node.js loader
.sucrase.js:
- sucrase/dist/register
.sucrase.jsx:
- sucrase/dist/register
.sucrase.ts:
- sucrase/dist/register
.sucrase.tsx:
- sucrase/dist/register
.swc.js:
- '@swc/register'
.swc.jsx:
- '@swc/register'
.swc.ts:
- '@swc/register'
.swc.tsx:
- '@swc/register'
.toml:
- toml-require
.ts:
- ts-node/register
- sucrase/register/ts
- '@babel/register'
- esbuild-register/dist/node
- '@swc/register'
.tsx:
- ts-node/register
- sucrase/register/tsx
- '@babel/register'
- esbuild-register/dist/node
- '@swc/register'
.yaml:
- yaml-hook/register
.yml:
- yaml-hook/register
jsVariants
The jsVariants
is the same mapping as above, but only include the extensions which are variants of JavaScript.
Supported extensions and their hooks
.babel.js:
- '@babel/register'
.babel.jsx:
- '@babel/register'
.babel.ts:
- '@babel/register'
.babel.tsx:
- '@babel/register'
.cjs:
- interpret/cjs-stub
.coffee:
- coffeescript/register
.coffee.md:
- coffeescript/register
.esbuild.js:
- esbuild-register/dist/node
.esbuild.jsx:
- esbuild-register/dist/node
.esbuild.ts:
- esbuild-register/dist/node
.esbuild.tsx:
- esbuild-register/dist/node
.esm.js:
- esm
.js:
- built-in node.js loader
.jsx:
- '@babel/register'
- sucrase/register/jsx
.litcoffee:
- coffeescript/register
.mdx:
- '@mdx-js/register'
.mjs:
- interpret/mjs-stub
.sucrase.js:
- sucrase/dist/register
.sucrase.jsx:
- sucrase/dist/register
.sucrase.ts:
- sucrase/dist/register
.sucrase.tsx:
- sucrase/dist/register
.swc.js:
- '@swc/register'
.swc.jsx:
- '@swc/register'
.swc.ts:
- '@swc/register'
.swc.tsx:
- '@swc/register'
.ts:
- ts-node/register
- sucrase/register/ts
- '@babel/register'
- esbuild-register/dist/node
- '@swc/register'
.tsx:
- ts-node/register
- sucrase/register/tsx
- '@babel/register'
- esbuild-register/dist/node
- '@swc/register'
MIT
FAQs
A dictionary of file extensions and associated module loaders.
The npm package interpret receives a total of 16,058,377 weekly downloads. As such, interpret popularity was classified as popular.
We found that interpret demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 4 open source maintainers collaborating on the project.
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.
Security News
At Node Congress, Socket CEO Feross Aboukhadijeh uncovers the darker aspects of open source, where applications that rely heavily on third-party dependencies can be exploited in supply chain attacks.
Research
Security News
The Socket Research team found this npm package includes code for collecting sensitive developer information, including your operating system username, Git username, and Git email.
Security News
OpenJS is warning of social engineering takeovers targeting open source projects after receiving a credible attempt on the foundation.