[Raymondo97]

This PR introduces the initial testing infrastructure and baseline specification tests for the upcoming Temporal proposal.

To ensure the test suite is manageable and easy to review, this initial PR focuses strictly on setting up the shared harness infrastructure, upgrading the build scripts to support future test suites, and providing a single flat baseline test for the Temporal namespace.

Key Changes

• Build & Tooling Upgrades:
  • Updated .gitignore to prevent local IDE files from polluting the working tree.
  • Applied a non-breaking regex fix (.replace(/\.js$/, '')) to scripts/build-indexes.mjs. This allows the index generator to safely handle future directory-based test suites (like es.temporal/duration/) without inadvertently slicing folder names.
• Centralized Harness Support: Added tests/helpers/temporal-helpers.js, porting vital assertion macros (e.g., assertDuration) and ISO constants from Test262. Assertions have been refactored to rely on passing the localized test framework context rather than assuming a leaked global context.
• Global & Pure Baselines: Created flat baseline files (tests/unit-global/es.temporal.js and tests/unit-pure/es.temporal.js) to verify the root namespace and basic descriptor intents (using safe target checks like Object.isExtensible).

Architectural Guardrails Included

• Wrapped property descriptor evaluations inside if (DESCRIPTORS) environments to maintain compatibility with legacy testing engines.
• Pure tests contain active safety gates to gracefully skip execution until the relative entry points are generated in core-js-pure.

[Raymondo97]

I did want to mention that the reason I decided to put the tests into a separate directory under the unit-pure and unit-global is due to the vast number of test that would need to be added (200+). We can either create a flat structure for all the Temporal property's tests, or we can nest those as well, similar to how the Test262 tests are structured.

[Raymondo97]

The changes made here do not pass the ESLint rules. I will mark the PR as ready when it succeeds, and the corrections are pushed up.

[Raymondo97]

я провірив все працює

Interesting. According to the ESLint rules, it shouldn’t pass. Especially for the unit-pure test. The temporal-helpers.js are also problematic. So unless I have my environment setup incorrectly, running npm run lint should throw errors.

[zloirock]

@stasyu2009-ux if you wanna say something, please, use English.

[zloirock]

@Raymondo97 sorry for the delayed reply. I am now fully focused on other tasks, I'll take a look in the next few days.

[Raymondo97]

@zloirock No worries at all! I see that you've been working incredibly hard on v4.

To be clear, this PR establishes the temporal-helpers.js infrastructure, the regex fix for the index builder, and one flat baseline test (es.temporal.js).

However, as I look at porting the rest of the Temporal tests from Test262, I'm realizing the sheer volume will be massive. Moving forward, I'm wondering if it may be beneficial to match Test262's layout. We could group the tests into sub-directories inside an es.temporal/ folder. For example:

tests/unit-global/
└── es.temporal/
    ├── index.js             // Hardcoded imports for sub-suites
    ├── duration/
    │   ├── index.js         
    │   ├── constructor.js
    │   └── ...
    ├── plain-date/
    │   ├── index.js
    │   └── ...
    └── instant/

In order to support this, we'd need to decide how to apply ESLint settings to it. By hardcoding the index.js files into each sub-directory, we would likely need to add 'tests/unit-@(global|pure)/es.temporal/index.js' to the ESLint ignores array. We could also relax the naming conventions for the files within the es.temporal/ directories to avoid redundancy.

(Note: to support importing folders like this in the future, I already included a small regex fix to scripts/build-indexes.mjs in this PR so the test generator doesn't strip characters off of folder names).

Would this nested approach align with your vision for the v3/v4 architecture, or would you prefer a different layout before I start porting the rest of the Test262 suite? I'll hold off on porting the massive test suites until I hear your thoughts on the architecture. I'm happy to adjust as needed!

[Raymondo97]

Hey @zloirock,
Hope you're doing well! I wanted to check in on this PR to see if porting these tests is still something you'd like to pursue for v3 / v4.

I saw that compat data mapping was recently added for Node 26 (which includes native Temporal support). While I know the engine-level BigInt limitation remains for standard polyfills on legacy engines without BigInt, having these Test262 suites ported over will help establish a complete compliance baseline—both for validating native behavior in runtimes like Node 26 and for testing future v4 implementations.

I'm still happy to continue porting the remaining Test262 sub-suites if this is helpful, or pivot if you have other priorities for v4. Let me know what works best for you!