`@std/assert` library throws in ESM typecheck after updating to `1.0.2`

joscha commented 2 months ago

After updating @std/assert I get:

src/deps/jsr.io/@std/assert/1.0.2/assertion_error.ts:27:42 - error TS2304: Cannot find name 'ErrorOptions'.

27   constructor(message: string, options?: ErrorOptions) {
                                            ~~~~~~~~~~~~
src/deps/jsr.io/@std/assert/1.0.2/assertion_error.ts:27:42 - error TS4063: Parameter 'options' of constructor from exported class has or is using private name 'ErrorOptions'.

27   constructor(message: string, options?: ErrorOptions) {
                                            ~~~~~~~~~~~~
src/deps/jsr.io/@std/assert/1.0.2/assertion_error.ts:28:20 - error TS2554: Expected 0-1 arguments, but got 2.

28     super(message, options);
                      ~~~~~~~
src/deps/jsr.io/@std/assert/1.0.2/object_match.ts:125:33 - error TS2339: Property 'intersection' does not exist on type 'Set<any>'.

125           filtered[key] = value.intersection(subset);
                                    ~~~~~~~~~~~~
src/deps/jsr.io/@std/assert/1.0.2/object_match.ts:187:31 - error TS2339: Property 'intersection' does not exist on type 'Set<any>'.

187           filtered.push(value.intersection(subset));
                                  ~~~~~~~~~~~~

error: Uncaught (in promise) Error: Had 5 diagnostics.
          throw new Error(`Had ${diagnostics.length} diagnostics.`);
                ^
    at getProgramAndMaybeTypeCheck (https://jsr.io/@deno/dnt/0.41.2/mod.ts:468:17)
    at build (https://jsr.io/@deno/dnt/0.41.2/mod.ts:354:17)
    at eventLoopTick (ext:core/01_core.js:168:7)
    at async file:///Users/joscha/dev/affinity-node/scripts/build_npm.ts:12:1

in the ESM type check step. Excluding via:

    filterDiagnostic(diagnostic: ts.Diagnostic) {
        if (
            diagnostic.file?.fileName.endsWith(
                'src/deps/jsr.io/@std/assert/1.0.2/assertion_error.ts',
            )
            ||
            diagnostic.file?.fileName.endsWith(
                'src/deps/jsr.io/@std/assert/1.0.2/object_match.ts',
            )
        ) {
            return false // ignore all diagnostics in this file
        }
        return true
    },

doesn't seem to work. Reference PR is here: https://github.com/planet-a-ventures/affinity-node/pull/31

joscha commented 2 months ago

Is it possible that when resolving the types for some of these files, it mixes an older version of the same code? I can see that:

      "@deno/dnt@0.41.2": {
        "integrity": "27bd0b42ab92ec1e892cb1f95e4b3bce84151dad89dadb422ccf5b3d7d026e9c",
        "dependencies": [
          "jsr:@deno/cache-dir@^0.8.0",
          "jsr:@std/fmt@^0.218.2",
          "jsr:@std/fs@^0.218.2",
          "jsr:@std/path@^0.218.2",
          "npm:@ts-morph/bootstrap@0.22",
          "npm:code-block-writer@^13.0.1"
        ]
      },

and:

      "@std/fs@0.218.2": {
        "integrity": "dd9431453f7282e8c577cc22c9e6d036055a9a980b5549f887d6012969fabcca",
        "dependencies": [
          "jsr:@std/assert@^0.218.2",
          "jsr:@std/path@^0.218.2"
        ]
      },

which means that dnt itself might possibly have loaded 0.218.2 of @std/assert

dsherret commented 2 months ago

I think @std/assert started using ESNext features. You might have to add the following to your build options (also, you might need to upgrade to dnt 0.41.3 (just released)):

  compilerOptions: {
    lib: ["ESNext"],
  },

joscha commented 2 months ago

updating dnt to 0.41.3 fixes the issue (without adding lib: ESNext).

joscha commented 2 months ago

I take it back, it only removes the errors with the filterDiagnostic code above.

joscha commented 2 months ago

  compilerOptions: {
    lib: ["ESNext"],
  },

This fixes it with @std/assert@1 and no needed filterDiagnostic

denoland / dnt

`@std/assert` library throws in ESM typecheck after updating to `1.0.2` #422