Skip to content
This repository was archived by the owner on Jul 31, 2018. It is now read-only.

proposal: Staged require() with lifecycle hooks #56

Closed
Qard wants to merge 4 commits into from
Closed

proposal: Staged require() with lifecycle hooks #56

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
375b0dc
proposal: Staged require() with lifecycle hooks
Qard May 6, 2017
3664146
elaborate on motivations a bit
Qard May 6, 2017
0e1f17b
rewrote hook-style a bit and added object-based style
Qard May 6, 2017
19247a4
minor revisions
Qard May 22, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
minor revisions
  • Loading branch information
@Qard
Qard committed May 22, 2017
commit 19247a4c648f44f74cc94406526064fcef1f4772
23 changes: 12 additions & 11 deletions XXX-staged-require-with-lifecycle-hooks.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -143,22 +143,23 @@ The final module object, built by the `compiler` stage.
## Hook-based

The idea here is to go for something similar to `Module._extensions`, but with
three stages: resolving, loading and compiling.
four stages: resolving, loading, transforming and compiling.

### `require.resolvers`

It is the responsibility of `require.resolvers` extension handlers to receive
Copy link
Copy Markdown

@sam-github sam-github May 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reminds me of https://www.lua.org/manual/5.1/manual.html#pdf-package.loaders

the in-process `Module` object and use the metadata on it to figure out how to
resolve a load. For `require()` relative location loading, it'd simply look at
the `parent` and resolve the input string of the `require()` call relative to
the `parent` module.
the in-process `ModuleRequest` object and use the metadata on it to figure out
how to resolve a load. For `require()` relative location loading, it'd simply
look at the `parent` and resolve the input string of the `require()` call
relative to the `parent` module.

This would roughly correspond to the current `Module._resolveLookupPaths`
implementation, but it should instead receive the module request object which
it will modify in-place.

The first resolver to return a non-null value would decide the `resolvedPath`
value in subsequent stages.
The first resolver to return a string would determine the `resolvedPath` field,
ending the resolver stage. It would then either pull an entry from the cache
which matches the path or would begin the loading stage.

```js
const mockedPaths = {
Expand All @@ -174,9 +175,9 @@ require.resolvers.push(({ inputPath }) => {

### `require.loaders`

The `require.loaders` extension handlers receive the `Module` object after the
`resolver` stage and use the resolved path to attempt to load the contents of
the module file.
The `require.loaders` extension handlers receive the `ModuleRequest` object
after the `resolver` stage and use the resolved path to attempt to load the
contents of the module file.

Returning `null` would skip to the next loader in the pipeline. If no loader
returns a value, a `MODULE_NOT_FOUND` error is thrown.
Expand Down Expand Up @@ -327,4 +328,4 @@ do that, thus the safer approach of an entirely new object.
- For the object-based style, it might also be a good idea to, rather than have
the `transform` method, have `preCompile` and `postCompile` transformers.

[1]: https://github.com/nodejs/node/blob/master/lib/_tls_wrap.js#L829
[1]: https://github.com/nodejs/node/blob/ed365653f6eb74d58a1d2a1c1bdb20e4baf67fa0/lib/_tls_wrap.js#L827