-
Notifications
You must be signed in to change notification settings - Fork 247
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
Update module and moduleResolution to stop using node and invalid combintations #197
Changes from 6 commits
a8c454f
449f1c9
b1eae8c
700981c
7f15ea0
7301ec5
4fd7c96
f2fd2b6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
|
@@ -2,15 +2,15 @@ | |||||
"$schema": "https://json.schemastore.org/tsconfig", | ||||||
"display": "Ember", | ||||||
"docs": "https://docs.ember-cli-typescript.com", | ||||||
"_version": "2.0.0", | ||||||
"_version": "2.1.0", | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As suggested on the main discussion, it would be helpful for us to treat this as 3.0.0 if it’s explicitly bumping the minimum TS version. However, I have not fully taken on the overall approach here. If (per the README change) it is going going to be effectively bumped with every release, we may need to reevaluate the approach. Ember itself is also at a point where we could poeple finally look at just shipping an There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Happy with whatever works for you - could bump to 4.x because that matches the LTS of embed for example too? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's just go with a clean major for now:
Suggested change
Medium-term, I think we'll probably end up switching to an |
||||||
|
||||||
// This is the base config used by Ember apps and addons. When actually used | ||||||
// via Ember CLI (e.g. ember-cli-typescript's blueprint), it additionally has | ||||||
// `compilerOptions.baseUrl`, `compilerOptions.paths`, and `include` set. | ||||||
"compilerOptions": { | ||||||
"target": "ES2021", | ||||||
"module": "ES2020", | ||||||
"moduleResolution": "node", | ||||||
"module": "esnext", | ||||||
"moduleResolution": "bundler", | ||||||
|
||||||
// Trying to check Ember apps and addons with `allowJs: true` is a recipe | ||||||
// for many unresolveable type errors, because with *considerable* extra | ||||||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,9 +1,11 @@ | ||
{ | ||
"_deprecated": true, | ||
"$schema": "https://json.schemastore.org/tsconfig", | ||
"display": "ESM", | ||
|
||
"compilerOptions": { | ||
"module": "es2022", | ||
"moduleResolution": "bundler", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I strongly object to this base existing at all. It’s a trap that might prevent a user from finding the config they should be using for Node or Vite or whatever. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I delisted it in the latest commit. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is the suggested approach to now use base/node18 and then set moduleResolution manually in tsconfig.json to bundler? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would like to know that as well. It's not clear to me what is the recommended config for ESM modules which target nodejs (particularly 22). What if it's modules shared between frontend and backend in a monorepo? |
||
|
||
"verbatimModuleSyntax": true | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,7 +11,7 @@ | |
"noEmit": true, | ||
"esModuleInterop": true, | ||
"module": "esnext", | ||
"moduleResolution": "node", | ||
"moduleResolution": "bundler", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This would be a breaking change in Next.js since its only TS 5+ While we're at it, we could probably remove Also You can find the latest with create next app |
||
"resolveJsonModule": true, | ||
"isolatedModules": true, | ||
"jsx": "preserve", | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,16 +1,17 @@ | ||
{ | ||
"$schema": "https://json.schemastore.org/tsconfig", | ||
"display": "Node 12", | ||
"_version": "12.1.0", | ||
|
||
"compilerOptions": { | ||
"lib": ["es2019", "es2020.promise", "es2020.bigint", "es2020.string"], | ||
"module": "commonjs", | ||
"module": "node16", | ||
"target": "es2019", | ||
|
||
"strict": true, | ||
"esModuleInterop": true, | ||
"skipLibCheck": true, | ||
"forceConsistentCasingInFileNames": true, | ||
"moduleResolution": "node" | ||
"moduleResolution": "node16" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The changes reflected in |
||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,16 +1,17 @@ | ||
{ | ||
"$schema": "https://json.schemastore.org/tsconfig", | ||
"display": "Node 14", | ||
"_version": "14.1.0", | ||
|
||
"compilerOptions": { | ||
"lib": ["es2020"], | ||
"module": "commonjs", | ||
"module": "node16", | ||
"target": "es2020", | ||
|
||
"strict": true, | ||
"esModuleInterop": true, | ||
"skipLibCheck": true, | ||
"forceConsistentCasingInFileNames": true, | ||
"moduleResolution": "node" | ||
"moduleResolution": "node16" | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,6 +11,6 @@ | |
"esModuleInterop": true, | ||
"skipLibCheck": true, | ||
"forceConsistentCasingInFileNames": true, | ||
"moduleResolution": "node" | ||
"moduleResolution": "node16" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No, it should match the module setting above (the linked PR on TS would enforce it). At the moment, node16 is nodenext, as no new resolution semantics have been introduced. Eventually maybe there will be a node24 if that version changes something. Related, but "node" was renamed to "node10" for that reason. |
||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,9 @@ | ||
// deno run --allow-read --allow-write scripts/generate-lts.ts | ||
// | ||
|
||
import { gt } from "https://deno.land/[email protected]/semver/gt.ts"; | ||
import { parse } from "https://deno.land/[email protected]/semver/parse.ts"; | ||
|
||
interface NodeReleaseMetadata { | ||
version: string; | ||
date: string; | ||
|
@@ -19,20 +22,12 @@ type Tsconfig = Record<string, any>; | |
|
||
const versionRegex = /v(\d+)\.(\d+)\.(\d+)/; | ||
|
||
function calcVersion(x: string) { | ||
const match = x.match(versionRegex); | ||
if (!match) { | ||
throw new Error(`version regex failed to match version string '${x}'`); | ||
} | ||
return +match[1] * 1000000 + +match[2] * 1000 + +match[3]; | ||
} | ||
|
||
const releasesResponse = await fetch("https://nodejs.org/download/release/index.json"); | ||
const releasesJson = (await releasesResponse.json()) as NodeReleaseMetadata[]; | ||
const lts = releasesJson | ||
.filter((r) => r.lts) | ||
.reduce( | ||
(prevValue, currValue) => (calcVersion(currValue.version) > calcVersion(prevValue.version) ? currValue : prevValue), | ||
(prevValue, currValue) => (gt(parse(currValue.version), parse(prevValue.version)) ? currValue : prevValue), | ||
{ | ||
version: "v0.0.0" | ||
} | ||
|
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.
Related: #196 and facebook/docusaurus#9050 (comment)