Giter Club home page Giter Club logo

ts-jest-resolver's Introduction

ts-jest-resolver

Build Status License

A resolver for jest that uses the same strategy as TS when resolving files with JavaScript extensions (".js", ".jsx", ".cjs" and ".mjs"). It works pretty well with ts-jest or babel with @babel/preset-typescript.

  • ๐Ÿ“ฆ Distributions in ESM and CommonJS.
    • Supports both Node.js ESM (import/export) and CommonJS (require/module.exports).
  • โšก Lightweight:
    • It's bundled using rollup.js.
  • ๐Ÿ”‹ Bateries included:
    • It just depends on jest-resolver types.
  • โœ… Safe:

Usage

This library is published in the NPM registry and can be installed using any compatible package manager.

npm install ts-jest-resolver --save

# For Yarn, use the command below.
yarn add ts-jest-resolver

After installation, you can set "ts-jest-resolver" as jest's resolver.

// jest.config.js

module.exports = {
  preset: "ts-jest",
  resolver: "ts-jest-resolver",
};

How it works

It changes module's extension to resolve in the same way as TypeScript.

How it works with ".js" and ".jsx" extensions

When importing from path with JavaScript extension (".js" or ".jsx"):

import EventEmitter from './EventEmitter.js';
  1. It tries to resolve to a path with ".tsx";

    import EventEmitter from './EventEmitter.tsx';
  2. If no file was found, it tries to resolve to a path with ".ts";

    import EventEmitter from './EventEmitter.ts';
  3. If no file was found, it resolves to original path (with ".js" or ".jsx").

    import EventEmitter from './EventEmitter.js';

How it works with ".mjs" and ".cjs" extensions

When importing from path with ES or CommonJS modules (".mjs" and ".cjs" respectively):

Ex.

import parse, { Tokenizer } from './parser.mjs'
import { discoverPath } from './getFiles.cjs';
  1. It tries to resolve to paths with ".mts" and ".cts".

    Ex.

    import parse, { Tokenizer } from './parser.mts'
    import { discoverPath } from './getFiles.cts';
  2. If no files were found, it resolves to original paths (with ".mjs" and ".cjs").

    Ex.

    import parse, { Tokenizer } from './parser.mjs'
    import { discoverPath } from './getFiles.cjs';

License

Released under MIT License.

ts-jest-resolver's People

Contributors

ra80533 avatar vitorluizc avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

ts-jest-resolver's Issues

Correct extensions resolution order?

I checked how TS resolves .js,.jsx,.mjs and .cjs imports.
For .cjs and .mjs it simply prefers TS version over a vanilla one, no issue here.
For both .js and .jsx import though, this is the resolution order I see - .ts, .tsx, .js, .jsx - so it looks for non-extended TS/JS at first.
I see this ordering was already corrected once here - 89afc07 - and this makes me even more curious on how things should actually be set.

In my experiment I used [email protected], "module": "node16" in tsconfig.json, "type": "module" in package.json.

I'm not sure the order I see in my setup is a single correct one, but I see divergence over different tools:

Logging this not to say the existing resolution is incorrect, but rather to discuss.
Could you recall, why ts-jest-resolver puts its preference to -x extensions over vanilla ones?

P.S.: things become even trickier if we add conditional exports/imports and self-references into the equation, so chasing consistency over different setups feels like a rat-race and I feel it might worth requesting support from TS-team on these, resolution-related matters.

Support require without extension

All of our TypeScript code uses imports without extensions. Example:

import * as module from './module';

This works because our code is in CommonJS; at compile time, TypeScript will know to look for module.ts or module.d.ts, at run-time Node will look for module.js.

Currently, ts-jest-resolver will not handle paths without extensions correctly: it will only replace known extensions with different ones, not try to add extensions to unqualified files.

I can write a PR to add this behavior. Would you accept it if I did?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.