Support custom user conditions in options

[ernestostifano]

TL;DR

It would be awesome if jiti could support custom user conditions in its options.

Something like:

conditions

• Type: Array
• Default: -
• Environment variable: JITI_CONDITIONS

Takes a list of additional conditions to be considered during resolving.

const jiti = createJiti(import.meta.url, { conditions: ['development'] });

Motivations

Setting --conditions in Node.js is not easy when third-party tools are involved and/or when we don't control how Node.js is invoked. See point 5 at "The Problem - TL;DR" in this Node.js Proposal.

I really think jiti could make a huge difference here while the ecosystem is transitioning into a more native solution. It could allow achieving 100% ESM/TypeScript projects in a clean way, from configuration files to implementation code.

To make this new feature work with ESM, we will need to reconsider #34, so to make options effective when using ESM loader register (e.g. development tools' ESM configuration files).

import "jiti/register";

.jitirc

JITI_CONDITIONS=['development']

I know the target is to go fully native (the above Node.js proposal is all about it), but there is still a lot of good jiti can do.

I would be happy to help implementing this! Hope to get some feedback.

Additional information

• Would you be willing to help implement this feature?

[ernestostifano]

Would like to start working on a draft implementation and make some tests.

Non functional requirements on mind:

• Implementation does not introduce any breaking changes.
• Implementation does not introduce additional overhead or if minimum overhead is inevitable, it only applies when explicitly using the new feature.
• Interfaces remain consistent.
• Documentation is updated.
• Code follows project conventions, best practices and is clean/readable.

After looking at the source code, I was thinking that instead of implementing .jitirc idea, we could access the "nearest package.json" file (relative to cwd) within the initialize hook, read the eventual conditions field from there and just pass it to the resolver by merging it with the specific context.

{
    "conditions": ["development"]
}

I known conditions is not a standard field (many aren't or only became later), but it would satisfy the requirements and would be aligned with the Node.js proposal linked above (see point 1 in "Proposal" section).

relative to cwd

Need to think about this part.

What do you think @pi0? If you give me green light, I can start.

EDIT:

• Found that jiti already had some undocumented support for conditions, at least in jiti.import:

{
  async import<T = unknown>(
    id: string,
    opts?: JitiResolveOptions & { default?: true },
  ): Promise<T> {
    const mod = await jitiRequire(ctx, id, { ...opts, async: true });
    return opts?.default ? (mod?.default ?? mod) : mod;
  }
}

JitiResolveOptions contains condtitions and it is passed to jitiResolve.