-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v3: Maximize compatibility #2065
Conversation
import elementToString from './helpers/element-to-string'; | ||
import collapseWhitespace from './helpers/collapse-whitespace'; | ||
import { toArray } from './helpers/node-list'; | ||
import exists from './assertions/exists.js'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extensions are required by the "node16" moduleResolution option.
(some browser projects (and whole ecosystems) also use this)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about moduleSuffixes to make it automatic?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the need here isn't for TS, exactly, I should have provided more context. When a package is using node16-style resolution (not necessarily the TS config option), all imports must have extensions. Bundlers generally abstract this away.
@@ -1,4 +1,4 @@ | |||
import { ExistsOptions } from '../assertions'; | |||
import type { ExistsOptions } from '../assertions.js'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the need for type here is enforced from verbatimModuleSyntax
-- more information in the tsconfig.json
@@ -20,11 +20,6 @@ | |||
"default": "./dist/es/index.js" | |||
} | |||
}, | |||
"typesVersions": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
turns out this wasn't needed -- the types field is a sufficient fallback for environments that don't support exports
(moduleResolution: node)
dce2f3d
to
5eb98b2
Compare
// These are also required when using | ||
// verbatimModuleSyntax, because it's an | ||
// ESM-only feature | ||
"target": "esnext", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@NullVoxPopuli on line 19 there's "target": "es5"
so this one is overridden
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks! #2080
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tbf it does stand out 😅
❯ pnpm test
> [email protected] test (…)/qunit-dom/packages/qunit-dom
> vitest
▲ [WARNING] Duplicate key "target" in object literal [duplicate-object-key]
tsconfig.json:19:4:
19 │ "target": "es5"
╵ ~~~~~~~~
The original key "target" is here:
tsconfig.json:12:4:
12 │ "target": "esnext",
╵ ~~~~~~~~
Blocked by: #2066
This is mostly TS focused, as folks have all sorts of different (probably incorrect, or suboptimal) tsconfig.jsons (in part because TS isn't well understood by many, and keeping up is generally hard!)
I've added 3 test apps for serving and quick reference guides for folks trying to figure out TS with qunit / qunit-dom.
Ran in to an issue though.
Jest doesn't support ESM (easly), so I'm going to remove it. Another PR.