Skip to content

feat: Add es-main compatibility to vite-node#4751

Merged
sheremet-va merged 1 commit intovitest-dev:mainfrom
zookatron:main
Dec 15, 2023
Merged

feat: Add es-main compatibility to vite-node#4751
sheremet-va merged 1 commit intovitest-dev:mainfrom
zookatron:main

Conversation

@zookatron
Copy link
Copy Markdown
Contributor

@zookatron zookatron commented Dec 14, 2023

Description

In ES modules, we can't use the traditional "require.main" method in node to figure out if the currently executing module is the main entry point for the node process. The es-main module provides a utility that lets us accomplish the same thing using import.main metadata that is available in ES modules. You can read more about this use case in the es-main module readme.

es-main expects process.argv[1] to be the path to the script entry point to figure out if the module is the main one, but it expects this to be an absolute path because this is how node always formats the argument. vite-node is extremely close to being able to support this properly because when the --script argument is provided it does populate the script entry point path in process.argv[1], but unfortunately it provides it as a relative path which doesn't work with es-main. This PR makes a very small change to make the process.argv[1] value that vite-node sets when the --script argument to be an absolute path, matching the behavior of normal NodeJS execution.

Without This Change

Using test.js:

import esMain from 'es-main';

console.log(esMain(import.meta) ? 'main' : 'not main');

Without this change the output of node test.js is main, but the output of vite-node --script test.js is not main.

With This Change

Using test.js:

import esMain from 'es-main';

console.log(esMain(import.meta) ? 'main' : 'not main');

With this change the output of node test.js is main, and the output of vite-node --script test.js is main.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

  • It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
  • Ideally, include a test that fails without this PR but passes with it.
  • Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

  • Run the tests with pnpm test:ci.

Documentation

  • If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

  • Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants