diff --git a/GOVERNANCE.md b/GOVERNANCE.md index dcfab1a..4425c3e 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -33,7 +33,7 @@ There is no specific set of requirements or qualifications for Team Membership b Changes to Team membership should be proposed with an issue and labelled `loaders-agenda` to be included in the next [team meeting](#team-meetings). Decisions are made via the -[Consensus Seeking Process](#consensus-seeking-process). If there are not objections in the +[Consensus Seeking Process](#consensus-seeking-process). If there are no objections in the issue new members may attend the meeting in which their membership is officially accepted. If a Team member is unable to attend a meeting where a planned membership decision is being made, @@ -114,7 +114,7 @@ user experience for ECMAScript, CommonJS, and other loaders supported by Node.js Pull requests not included under the _special exemptions_ section below must reach consensus in a meeting in order to be merged into this repository. A pull -request that is is unable to reach consensus cannot be merged into this +request that is unable to reach consensus cannot be merged into this repository. ### Special Exemptions to the PR landing process diff --git a/README.md b/README.md index 1a122f3..83fad72 100644 --- a/README.md +++ b/README.md @@ -40,7 +40,7 @@ This team is spun off from the [Modules team](https://github.com/nodejs/modules) - [ ] Start with helpers for retrieving the closest parent `package.json` associated with a specifier string; and for retrieving the `package.json` for a particular package by name (which is not necessarily the same result). - - [ ] Potentially include all the functions that make up the ESM resolution algorithm as defined in the [spec](https://nodejs.org/api/esm.html#resolution-algorithm-specification). Create helper functions for each of the functions defined in that psuedocode: `esmResolve`, `packageImportsResolve`, `packageResolve`, `esmFileFormat`, `packageSelfResolve`, `readPackageJson`, `packageExportsResolve`, `lookupPackageScope`, `packageTargetResolve`, `packageImportsExportsResolve`, `patternKeyCompare`. (Not necessarily all with these exact names, but corresponding to these functions from the spec.) + - [ ] Potentially include all the functions that make up the ESM resolution algorithm as defined in the [spec](https://nodejs.org/api/esm.html#resolution-algorithm-specification). Create helper functions for each of the functions defined in that pseudocode: `esmResolve`, `packageImportsResolve`, `packageResolve`, `esmFileFormat`, `packageSelfResolve`, `readPackageJson`, `packageExportsResolve`, `lookupPackageScope`, `packageTargetResolve`, `packageImportsExportsResolve`, `patternKeyCompare`. (Not necessarily all with these exact names, but corresponding to these functions from the spec.) - [ ] Follow up with similar helper functions that make up what happens within Node’s internal `load`. (Definitions to come.) diff --git a/doc/design/proposal-ambient-loaders.md b/doc/design/proposal-ambient-loaders.md index 33eb016..15d1dab 100644 --- a/doc/design/proposal-ambient-loaders.md +++ b/doc/design/proposal-ambient-loaders.md @@ -48,7 +48,7 @@ Let’s imagine we have the following loaders: - yaml, which adds yaml file support to `import` - coffeescript, which adds coffeescript file support to `import` -The first two are critical to a successful resolution: without `zip`, PnP wouldn't be able to load files from the zip archives. Without `pnp`, Node would look for the `yaml` and `coffeescript` loaders into a `node_modules` folder, which would fail. On the other hand, `yaml` and `coffeescript` don't depend on each other. +The first two are critical to a successful resolution: without `zip`, PnP wouldn't be able to load files from the zip archives. Without `pnp`, Node would look for the `yaml` and `coffeescript` loaders in a `node_modules` folder, which would fail. On the other hand, `yaml` and `coffeescript` don't depend on each other. The command line would end up like this (in practice `--ambient-loader` would probably be passed via `NODE_OPTIONS` rather than directly on the command line): diff --git a/doc/design/proposal-chaining-iterative.md b/doc/design/proposal-chaining-iterative.md index b3d75f3..9dd8462 100644 --- a/doc/design/proposal-chaining-iterative.md +++ b/doc/design/proposal-chaining-iterative.md @@ -4,7 +4,7 @@ Say you had a chain of three loaders: -1. `unpkg` resolves a specifier `foo` to an URL `http://unpkg.com/foo`. +1. `unpkg` resolves a specifier `foo` to a URL `http://unpkg.com/foo`. 2. `http-to-https` rewrites that URL to `https://unpkg.com/foo`. 3. `cache-buster` takes the URL and adds a timestamp to the end, like `https://unpkg.com/foo?ts=1234567890`. @@ -76,7 +76,7 @@ export async function resolve( ) { const url = new URL(interimResult.url); // this can throw, so handle appropriately - if (url.protocol = 'http:') url.protocol = 'https:'; + if (url.protocol === 'http:') url.protocol = 'https:'; return { url: url.toString() }; } @@ -210,7 +210,7 @@ const mimeTypeToFormat = new Map([ export async function load( interimResult, // possibly output of https-loader context, - defaulLoad, + defaultLoad, ) { const { resolvedUrl } = context; if (!coffeescriptExtensionsRgx.test(resolvedUrl)) return; // step aside @@ -220,7 +220,7 @@ export async function load( const rawSource = ( interimResult.source - || await defaulLoad(resolvedUrl, { ...context, format }).source + || await defaultLoad(resolvedUrl, { ...context, format }).source ) const transformedSource = CoffeeScript.compile(rawSource.toString(), { bare: true, @@ -247,7 +247,7 @@ const coffeescriptExtensionsRgs = /* … */ export async function load( interimResult, // possibly output of coffeescript-loader context, - defaulLoad, + defaultLoad, ) { const { resolvedUrl } = context; const babelConfig = await getBabelConfig(resolvedUrl); @@ -261,7 +261,7 @@ export async function load( const sourceToTranspile = ( interimResult.source - || await defaulLoad(resolvedUrl, { ...context, format }).source + || await defaultLoad(resolvedUrl, { ...context, format }).source ); const transformedSource = Babel.transformSync( sourceToTranspile.toString(), diff --git a/doc/design/proposal-chaining-middleware.md b/doc/design/proposal-chaining-middleware.md index 41a481c..6c71f49 100644 --- a/doc/design/proposal-chaining-middleware.md +++ b/doc/design/proposal-chaining-middleware.md @@ -4,7 +4,7 @@ Say you had a chain of three loaders: -1. `unpkg` resolves a specifier `foo` to an URL `http://unpkg.com/foo`. +1. `unpkg` resolves a specifier `foo` to a URL `http://unpkg.com/foo`. 2. `http-to-https` rewrites that URL to `https://unpkg.com/foo`. 3. `cache-buster` takes the URL and adds a timestamp to the end, like `https://unpkg.com/foo?ts=1234567890`. @@ -59,7 +59,7 @@ export async function resolve( const url = new URL(result.url); - if (url.protocol !== 'data:')) { // `data:` URLs don’t support query strings + if (url.protocol !== 'data:') { // `data:` URLs don’t support query strings url.searchParams.set('ts', Date.now()); } diff --git a/doc/design/proposal-strip-types.md b/doc/design/proposal-strip-types.md index 4d12c87..d149a63 100644 --- a/doc/design/proposal-strip-types.md +++ b/doc/design/proposal-strip-types.md @@ -3,7 +3,7 @@ ## Problem TypeScript support has been for a few years at the top of the list of features that users want to see in Node.js. -Discussion has been on going for a few years [#43818](https://github.com/nodejs/node/issues/43818), and the main blocker has been the lack of a clear on long term support. +Discussion has been ongoing for a few years [#43818](https://github.com/nodejs/node/issues/43818), and the main blocker has been the lack of a clear long-term support. TypeScript does not follow semver, and the Node.js project has been reluctant to commit to supporting TypeScript in the long term, given that the lifespan of an LTS version is 3 years. ## Goals @@ -58,7 +58,7 @@ This is an issue that should apply to all tools that execute TypeScript at runti ### No type checking Type checking should be done by user land tools during development, and not at runtime. -By performing at runtime, we would be adding large overhead. +By performing it at runtime, we would be adding large overhead. ### Running TypeScript in node_modules diff --git a/doc/meetings/2024-06-18.md b/doc/meetings/2024-06-18.md index 7a14896..ecfc327 100644 --- a/doc/meetings/2024-06-18.md +++ b/doc/meetings/2024-06-18.md @@ -51,7 +51,7 @@ * Jakob: how would it be for preImport to be async and resolve and load be sync. What happens if preImport is not done * Guy: preImport blocks. Not doing any module graph linking until the promise of preImport finishes. Works with dynamic import because dynamic import is async. It wouldn’t work for require(esm) either. The same constraints apply for CJS that it can not require(network). * Geoffrey: it doesn’t work with TLA, the same restriction. Can not work with require(TLA) - * Geoffrey: based on Joyee’s design doc, make a new doc describe resole and load migrate to on-thread, synchronizing, describe what happens to register, and land it and implement it on main before october. + * Geoffrey: based on Joyee’s design doc, make a new doc describe resolve and load migrate to on-thread, synchronizing, describe what happens to register, and land it and implement it on main before october. * Geoffrey: preImport hook as a follow-up. * Jakob: design doc is the way to go. * Joyee: might be too much on my doc? @@ -66,7 +66,7 @@ * Geoffrey: not on a main thread, doesn’t mean you are on a loader thread * Guy: the current register model is really great, you * Guy: Joyee’s model is not obvious how a worker is attached. Automatically get registered loaders work for worker threads would be great - * Joyee: whether sharing source code or instances. I think people are strongly against having shared instances across threads. Nice to have a shared configuration, rather than shread instance. Someone from sentry: is there a way to configure loader, instead of loading a package. + * Joyee: whether sharing source code or instances. I think people are strongly against having shared instances across threads. Nice to have a shared configuration, rather than shared instance. Someone from sentry: is there a way to configure loader, instead of loading a package. * Joyee: API seems for instance. configuration for source codes. * Guy: beneficial to have a worker inherit configured loaders * Joyee: most intuitive behavior people in issues, suppose you don’t want to share? diff --git a/doc/meetings/2024-07-02.md b/doc/meetings/2024-07-02.md index f03aab5..bff8b2a 100644 --- a/doc/meetings/2024-07-02.md +++ b/doc/meetings/2024-07-02.md @@ -42,7 +42,7 @@ * Joyee: At least for Node.js the ship has shipped that you can do anything, like spawning a process. Browsers are supposed to run untrusted code. Node.js runs trusted code, that is the security model. * Geoffrey: @joyee what’s your opinion on inheriting main thread’s loader settings? * Joyee: in the thread, people want it to be able to configure at library level and user level. - * Geoffrey: a user case is that TypeScript loaders. As an author of TypeScript library, a user register TypeScript loader at the entry, within the library, it can decide if it wants register in the worker or child process. What would the downside be the confiurability here. + * Geoffrey: a use case is that TypeScript loaders. As an author of TypeScript library, a user register TypeScript loader at the entry, within the library, it can decide if it wants register in the worker or child process. What would the downside be the configurability here. * Guy: I think loader authors won’t think about worker that much. On the API side, needs clarification on how the registration works. ### Open Discussion diff --git a/doc/roadmap-2024.md b/doc/roadmap-2024.md index 83d797a..4655121 100644 --- a/doc/roadmap-2024.md +++ b/doc/roadmap-2024.md @@ -44,7 +44,7 @@ Before extending into new frontiers, we need to improve the loaders API enough t - [ ] Start with helpers for retrieving the closest parent `package.json` associated with a specifier string; and for retrieving the `package.json` for a particular package by name (which is not necessarily the same result). - - [ ] Potentially include all the functions that make up the ESM resolution algorithm as defined in the [spec](https://nodejs.org/api/esm.html#resolution-algorithm-specification). Create helper functions for each of the functions defined in that psuedocode: `esmResolve`, `packageImportsResolve`, `packageResolve`, `esmFileFormat`, `packageSelfResolve`, `readPackageJson`, `packageExportsResolve`, `lookupPackageScope`, `packageTargetResolve`, `packageImportsExportsResolve`, `patternKeyCompare`. (Not necessarily all with these exact names, but corresponding to these functions from the spec.) + - [ ] Potentially include all the functions that make up the ESM resolution algorithm as defined in the [spec](https://nodejs.org/api/esm.html#resolution-algorithm-specification). Create helper functions for each of the functions defined in that pseudocode: `esmResolve`, `packageImportsResolve`, `packageResolve`, `esmFileFormat`, `packageSelfResolve`, `readPackageJson`, `packageExportsResolve`, `lookupPackageScope`, `packageTargetResolve`, `packageImportsExportsResolve`, `patternKeyCompare`. (Not necessarily all with these exact names, but corresponding to these functions from the spec.) - [ ] Follow up with similar helper functions that make up what happens within Node’s internal `load`. (Definitions to come.)