GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Using `node:test` with Custom ESM Loaders · Issue #46292 · nodejs/node

Using node:test with Custom ESM Loaders #46292

New issue
Copy link
New issue
Copy link
Closed
Closed
Using node:test with Custom ESM Loaders#46292
Copy link
Labels
feature requestIssues requesting new Node.js features.Issues requesting new Node.js features.test_runnerIssues and PRs related to the test runner subsystem.Issues and PRs related to the test runner subsystem.

Description

@shanewholloway
shanewholloway
opened on Jan 20, 2023
Issue body actions

What is the problem this feature will solve?

The builtin node:test functionality does not accommodate Custom ESM Loaders for specifying tests. The documented test-runner-execution-mode only matches .js | .cjs | .mjs extension files.

What is the feature you are proposing to solve the problem?

Ideally, the test-runner-execution-mode would allow for registered Custom ESM Loaders automatically. If not possible, specifying allowed file extensions via environment variable would work.

What alternatives have you considered?

Current workaround is a manual shim -- using a standard file extension and importing the Custom ESM modules from there.

Reacted by Fardjad Davari, mori yuta, Steven, Scott Moore and Daniel Perez

Activity

  1. shanewholloway
    added
    feature requestIssues requesting new Node.js features.Issues requesting new Node.js features.
    on Jan 20, 2023
  2. aduh95 commented on Jan 21, 2023

    @aduh95
    aduh95
    on Jan 21, 2023
    Contributor
    More actions

    FWIW here's the workaround I'm using on a project of mine:

    // test/index.ts
    import fs from "node:fs/promises";
    
    async function* findTestFiles(url) {
      for await (const dirent of await fs.opendir(url)) {
        if (dirent.name === "node_modules" || dirent.name.startsWith(".")) continue;
    
        if (dirent.isDirectory())
          yield* findTestFiles(new URL(`${dirent.name}/`, url));
        else if (dirent.name.endsWith(".test.ts")) yield new URL(dirent.name, url);
      }
    }
    
    for await (const file of findTestFiles(new URL("../", import.meta.url))) {
      await import(file);
    }

    And I have this in my package.json:

    {
      "scripts": {
        "test": "node --loader '#ts-loader' test/index.ts",
        "test-only": "node --test-only --loader '#ts-loader' test/index.ts"
      }
    }

    The above "just works" if you're using node:test (or any other test lib btw).

    You can also specify custom loader hooks in the NODE_OPTIONS env variable, which is then used by node --test when loading sub-files.

    But I guess what you meant was asking for a solution to provide custom file extensions / file name patterns for --test CLI flag, which I agree would be nice and doesn't have a solution yet. There have been discussions around adding a config file for Node.js entrypoint to specify those kind of things (file name patterns for --test, custom loader hooks, etc.) but no one is championing this AFAIK. I personally kind of wish that userland would come up with ad-hoc solutions and we would just have to pick the most popular one so we know the API is aligned with what the community needs/wants.

    Reacted by Jarek Rencz
    Reacted by Toni Villena, Steven and Thomas.G
  3. shanewholloway commented on Jan 23, 2023

    @shanewholloway
    shanewholloway
    on Jan 23, 2023
    Author
    More actions

    Thanks for the concise and helpful findTestFiles workaround code.

    Yes, I'm advocating for direct support of custom loader files in the test suite. It would allow for leveraging features like parallelization in the new node:test runner. As it is now, I'm excited to have a builtin test system, file watcher, and custom loaders!

  4. MoLow
    added
    test_runnerIssues and PRs related to the test runner subsystem.Issues and PRs related to the test runner subsystem.
    on Jan 24, 2023
  5. MoLow commented on Jan 24, 2023

    @MoLow
    MoLow
    on Jan 24, 2023
    Member
    More actions

    Ideally I would love if the test runner can support a glob expression, that will require glob support in core

  6. targos
    added this to Node.js feature requestson Mar 10, 2023
  7. github-project-automation
    moved this to Pending Triage in Node.js feature requestson Mar 10, 2023
  8. MoLow
    linked a pull request that will close this issuetest_runner: support passing globs #47653on May 15, 2023
  9. MoLow
    closed this as completedon Jun 25, 2023
  10. robcresswell commented on Jul 1, 2023

    @robcresswell
    robcresswell
    on Jul 1, 2023
    More actions

    In case anyone else is following this, I think this is solved by #47653 from @MoLow as referenced above; it was somewhat difficult for me to understand because the CI seems to use some kind of magic and "closes" PRs instead of "merging" them

    Reacted by Moshe Atlow
  11. avivkeller
    removed this from Node.js feature requestson Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestIssues requesting new Node.js features.Issues requesting new Node.js features.test_runnerIssues and PRs related to the test runner subsystem.Issues and PRs related to the test runner subsystem.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.