js-temporal/temporal-polyfill

What could cause two different instances of the slots WeakMap to be created?

Closed this issue · 2 comments

I'm working my may through a large project and converting it over to use Temporal, and I'm stumped by a problem I'm seeing where a PlainDate instance is created by internal Temporal code, and then that instance is rejected (again by Temporal's own internal code) as invalid. When I stepped through in the debugger, the problem seems to be that the slots WeakMap is somehow different between one line in ecmascript.ts and the next line! Here's the code where it fails:

  DateFromFields: (calendar, fields, options) => {
    const dateFromFields = ES.GetMethod(calendar, 'dateFromFields');
    const result = ES.Call(dateFromFields, calendar, [fields, options]);
       //  `result` is a valid Temporal instance, e.g. its methods return valid values, etc.
       //  When the line above runs, the `slots` WeakMap contains ~100 objects 
    if (!ES.IsTemporalDate(result)) throw new TypeError('invalid result');
       // but this line above throws, because when this code runs, the 
       // `slots` WeakMap only contains one object
    return result;
  },

I tried setting a breakpoint on the line in slots.ts where the slots object is actually created, and that breakpoint is only being hit once.

FWIW, this Temporal package is not from npm but instead is custom-built to remove type:"module" per #29, because otherwise the polyfill won't run at all. I'm npm install-ing it from the local .tgz file created by npm pack.

At this point I'm stumped. Any idea what could be causing this?

The problem turned out to be that VSCode's "auto-import" feature for some reason decided to import {Temporal } from '../node_modules/@js-temporal/polyfill' in one source file (the one that was failing above) instead of import {Temporal } from '@js-temporal/polyfill' like all other source files in my project. No idea why. When I fixed the import, the problem went away.

It was a good lesson that different ways of importing exactly the same code can have an interesting impact.

I'll close this issue now, but won't delete it in case someone else runs into the same problem in the future.