Skip to content
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

src: restructure modules and bootstrappers #19177

Closed
wants to merge 4 commits into from

Conversation

joyeecheung
Copy link
Member

@joyeecheung joyeecheung commented Mar 6, 2018

Refs: #19112

src: put bootstrappers in lib/internal/bootstrap/

Create lib/internal/bootstrap/ and put bootstrappers there:

Before:

lib/internal
├── ...
├── bootstrap_loaders.js
└── bootstrap_node.js

After:

lib/internal
├── ...
└── bootstrap
    ├── loaders.js
    └── node.js

lib: restructure cjsm and esm loaders

Create lib/internal/modules and restructure the module loaders
to make the purpose of those files clearer.

Also make it clear in the code that the object exported by
lib/internal/modules/cjsm.js is CJSModule instead of the
ambiguous Module.

Before (three files named module.js without any indication of
what they are implementing):

lib
├── ...
├── internal
│       ├── process
│       │     └── module.js
│       ├── loaders
│       │     ├── CreateDynamicModule.js
│       │     ├── DefaultResolve.js
│       │     ├── Loader.js
│       │     ├── ModuleJob.js
│       │     ├── ModuleMap.js
│       │     └── Translators.js
│       └── module.js
└── module.js

After (file names indicate the implemented module style):

├── ...
├── internal
│       ├── ...
│       ├── process
│       │     └── esm_loader.js
│       └── modules
│              ├── cjs
│              │     ├── helpers.js
│              │     └── loader.js
│              └── esm
│                    ├── CreateDynamicModule.js
│                    ├── DefaultResolve.js
│                    ├── Loader.js
│                    ├── ModuleJob.js
│                    ├── ModuleMap.js
│                    └── Translators.js
└── module.js
Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added the lib / src Issues and PRs related to general changes in the lib or src directory. label Mar 6, 2018
@joyeecheung
Copy link
Member Author

cc @devsnek

lib/module.js Outdated

// backwards compatibility
Module.Module = Module;
module.exports = require('internal/modules/cjsm');
Copy link
Member

Choose a reason for hiding this comment

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

I don’t think git recognizes this as a file move, so it won’t say anything about merge conflicts? That might be okay, we don’t have many PRs against this file open/to backport, I think…

Copy link
Member Author

Choose a reason for hiding this comment

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

@addaleax If we don't require that each commit must pass the test, we can delete the file first (so it will be recognized as a move) and then add the redirection later.

Copy link
Member

@devsnek devsnek left a comment

Choose a reason for hiding this comment

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

internal/modules/helper.js should definitely be moved to internal/modules/cjs/helper.js and internal/modules/cjsm.js should be internal/modules/cjs.js or tbh i think it was fine in module.js

aside from that i worry about packages like trace.js clarify possibly getting killed by at Module._compile (module.js) becoming at Module._compile (internal/modules/cjsm.js) but i haven't looked into that too deeply, so it might not be an issue

@joyeecheung
Copy link
Member Author

joyeecheung commented Mar 6, 2018

@devsnek I understand that the current internal/modules/helper.js can be renamed as internal/modules/cjs/helper.js (although my thinking is that we can add common helpers there so it does not need to be in any subdirectory. Things like stripBOM aren't really tied to any loader implementations).

Bikeshedding question: why does it need to be cjs instead of cjsm? CommonJS is not the equivalent of CommonJS Modules, just like ECMAScript is not the equivalent of ECMAScript Modules (although we are not respecting the original specs in things like assert either).

aside from that i worry about packages like trace possibly getting killed by at Module._compile (module.js) becoming at Module._compile (internal/modules/cjsm.js) but i haven't looked into that too deeply, so it might not be an issue

cc @AndreasMadsen although I don't think we should encourage user land modules to depend on our source positions..

@devsnek
Copy link
Member

devsnek commented Mar 6, 2018

@joyeecheung

Things like stripBOM aren't really tied to any loader implementations).

perhaps a better alternative would be moving that require building stuff out of the file then.

Bikeshedding question: why does it need to be cjs instead of cjsm?

everywhere else in the codebase that we shorten it we call it cjs, that's my only reasoning for it.

@joyeecheung
Copy link
Member Author

I also realize that there is the internal/process/module.js that should probably be renamed to internal/process/esm_loader.js since it's specific to setting up the ESM loader.

@joyeecheung
Copy link
Member Author

everywhere else in the codebase that we shorten it we call it cjs, that's my only reasoning for it.

Looks like this has already been documented in the resolve hook formats..unfortunate, but probably better name the directory as cjs as well for consistency

@joyeecheung
Copy link
Member Author

aside from that i worry about packages like trace.js clarify possibly getting killed by at Module._compile (module.js) becoming at Module._compile (internal/modules/cjsm.js) but i haven't looked into that too deeply, so it might not be an issue

I ran the test of clarify, it seems to be able to exclude all modules starting with internal so that should not be a problem.

@joyeecheung joyeecheung force-pushed the rename-modules branch 5 times, most recently from 0e24abf to cf967f4 Compare March 6, 2018 21:05
@joyeecheung
Copy link
Member Author

@devsnek I've changed the structure, it now looks like this:

lib
├── ...
├── internal
│       ├── ...
│       └── modules
│              ├── cjs
│              │     ├── helpers.js
│              │     └── loader.js
│              └── esm
│                    ├── CreateDynamicModule.js
│                    ├── DefaultResolve.js
│                    ├── Loader.js
│                    ├── ModuleJob.js
│                    ├── ModuleMap.js
│                    └── Translators.js
└── module.js

PTAL, thanks!

Copy link
Member

@devsnek devsnek left a comment

Choose a reason for hiding this comment

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

nit: const internalModule = require('internal/modules/cjs/helpers'); is a bit weird to look at, maybe the file should be called internalModule?

@joyeecheung
Copy link
Member Author

joyeecheung commented Mar 6, 2018

@addaleax BTW, the file mode conflicts can be solved with this:

git format-patch <sha>~1...<sha>
# suppose the output is `0001-test.patch`
sed -i '' -E "s/lib\/module.js/lib\/internal\/modules\/cjs\/loader.js/" 0001-test.patch
git am -3 0001-test.patch

If there are future backports (although given our stability concerns around the CJS loader implementation that should be rare), we just need to replace the lib/module.js in the email-formatted patch with lib/internal/module/cjs/loader.js and apply it with git am -3

@joyeecheung
Copy link
Member Author

@devsnek I think it's the variable that should be renamed to helpers? I believe they were named internalModule because the file was internal/module, not the other way around..

@joyeecheung
Copy link
Member Author

@devsnek Hmm, so the only const internalModule = require('internal/modules/cjs/helpers'); left are the test test-module-require-depth and its fixtures..I changed to use destructuring instead since they only need the const values of requireDepth.

@joyeecheung
Copy link
Member Author

@joyeecheung joyeecheung added module Issues and PRs related to the module subsystem. esm Issues and PRs related to the ECMAScript Modules implementation. labels Mar 6, 2018
@joyeecheung
Copy link
Member Author

@AndreasMadsen
Copy link
Member

aside from that i worry about packages like trace possibly getting killed by at Module._compile (module.js) becoming at Module._compile (internal/modules/cjsm.js) but i haven't looked into that too deeply, so it might not be an issue

cc @AndreasMadsen although I don't think we should encourage user land modules to depend on our source positions.

It should still work. The name.startsWith('internal') check will match internal/modules/cjsm.js.

@@ -86,7 +86,9 @@ function extractFunctionName(description) {

const NATIVES = process.binding('natives');
function isNativeUrl(url) {
return url.replace('.js', '') in NATIVES || url === 'bootstrap_node.js';
return url.replace('.js', '') in NATIVES ||
Copy link
Member

Choose a reason for hiding this comment

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

Should a PR be opened against https://github.com/nodejs/node-inspect before this lands so it doesn't get forgotten?

Also, strictly speaking, this change should either be in the same or preceding commit to the actual filename change (rather than after it), as otherwise node-inspect is broken.

(I just skimmed the PR so I could be totally off base.)

Copy link
Member Author

@joyeecheung joyeecheung Mar 8, 2018

Choose a reason for hiding this comment

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

@apapirovski I just realized this is not necessary since

> Object.keys(process.binding('natives'))
[ 'internal/bootstrap/loaders',
  'internal/bootstrap/node',
  ...

node-inspect only needed to test 'bootstrap_node.js' because it was internal/bootstrap_node.js but it didn't get named that way when being compiled.

@joyeecheung joyeecheung force-pushed the rename-modules branch 2 times, most recently from 27f010a to 3ebaa39 Compare March 8, 2018 16:30
@MylesBorins
Copy link
Contributor

Should this be backported to v9.x-staging? If yes please follow the guide and raise a backport PR, if not let me know or add the dont-land-on label.

MylesBorins pushed a commit that referenced this pull request Mar 20, 2018
Otherwise the debug log output might be mixed up with
the expected errors and the assertion matching the error
message would fail.

PR-URL: #19177
Refs: #19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
@joyeecheung
Copy link
Member Author

@MylesBorins Backport opened in #19374 , somehow I forgot to reference the PR from there so it did not show up in this thread

joyeecheung added a commit to joyeecheung/node that referenced this pull request Mar 30, 2018
Otherwise the debug log output might be mixed up with
the expected errors and the assertion matching the error
message would fail.

PR-URL: nodejs#19177
Refs: nodejs#19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
joyeecheung added a commit to joyeecheung/node that referenced this pull request Mar 30, 2018
Create `lib/internal/bootstrap/` and put bootstrappers there:

Before:

```
lib/internal
├── ...
├── bootstrap_loaders.js
└── bootstrap_node.js
```

After:

```
lib/internal
├── ...
└── bootstrap
    ├── loaders.js
    └── node.js
```

PR-URL: nodejs#19177
Refs: nodejs#19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
joyeecheung added a commit to joyeecheung/node that referenced this pull request Mar 30, 2018
Create `lib/internal/modules` and restructure the module loaders
to make the purpose of those files clearer.

Also make it clear in the code that the object exported by
`lib/internal/modules/cjs/loader.js` is `CJSModule` instead of the
ambiguous `Module`.

Before:

```
lib
├── ...
├── internal
│       ├── loaders
│       │     ├── CreateDynamicModule.js
│       │     ├── DefaultResolve.js
│       │     ├── Loader.js
│       │     ├── ModuleJob.js
│       │     ├── ModuleMap.js
│       │     ├── ModuleWrap.js
│       │     └── Translators.js
│       └── module.js
└── module.js
```

After:

```
lib
├── ...
├── internal
│       ├── ...
│       └── modules
│              ├── cjs
│              │     ├── helpers.js
│              │     └── loader.js
│              └── esm
│                    ├── CreateDynamicModule.js
│                    ├── DefaultResolve.js
│                    ├── Loader.js
│                    ├── ModuleJob.js
│                    ├── ModuleMap.js
│                    └── Translators.js
└── module.js # deleted in this commit to work with git file mode
```

PR-URL: nodejs#19177
Refs: nodejs#19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
joyeecheung added a commit to joyeecheung/node that referenced this pull request Mar 30, 2018
The previous commit deleted lib/module.js so that git
recognize the file move `lib/module.js` ->
`lib/internal/modules/cjs/loader.js`. This commit add the
redirection back.

PR-URL: nodejs#19177
Refs: nodejs#19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
targos pushed a commit that referenced this pull request Apr 4, 2018
Create `lib/internal/bootstrap/` and put bootstrappers there:

Before:

```
lib/internal
├── ...
├── bootstrap_loaders.js
└── bootstrap_node.js
```

After:

```
lib/internal
├── ...
└── bootstrap
    ├── loaders.js
    └── node.js
```

Backport-PR-URL: #19374
PR-URL: #19177
Refs: #19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
targos pushed a commit that referenced this pull request Apr 4, 2018
Otherwise the debug log output might be mixed up with
the expected errors and the assertion matching the error
message would fail.

Backport-PR-URL: #19374
PR-URL: #19177
Refs: #19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
targos pushed a commit that referenced this pull request Apr 4, 2018
Create `lib/internal/modules` and restructure the module loaders
to make the purpose of those files clearer.

Also make it clear in the code that the object exported by
`lib/internal/modules/cjs/loader.js` is `CJSModule` instead of the
ambiguous `Module`.

Before:

```
lib
├── ...
├── internal
│       ├── loaders
│       │     ├── CreateDynamicModule.js
│       │     ├── DefaultResolve.js
│       │     ├── Loader.js
│       │     ├── ModuleJob.js
│       │     ├── ModuleMap.js
│       │     ├── ModuleWrap.js
│       │     └── Translators.js
│       └── module.js
└── module.js
```

After:

```
lib
├── ...
├── internal
│       ├── ...
│       └── modules
│              ├── cjs
│              │     ├── helpers.js
│              │     └── loader.js
│              └── esm
│                    ├── CreateDynamicModule.js
│                    ├── DefaultResolve.js
│                    ├── Loader.js
│                    ├── ModuleJob.js
│                    ├── ModuleMap.js
│                    └── Translators.js
└── module.js # deleted in this commit to work with git file mode
```

Backport-PR-URL: #19374
PR-URL: #19177
Refs: #19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
targos pushed a commit that referenced this pull request Apr 4, 2018
The previous commit deleted lib/module.js so that git
recognize the file move `lib/module.js` ->
`lib/internal/modules/cjs/loader.js`. This commit add the
redirection back.

Backport-PR-URL: #19374
PR-URL: #19177
Refs: #19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
@targos targos mentioned this pull request Apr 4, 2018
@BridgeAR BridgeAR mentioned this pull request May 1, 2018
4 tasks
joyeecheung added a commit to joyeecheung/node that referenced this pull request Jun 13, 2018
Otherwise the debug log output might be mixed up with
the expected errors and the assertion matching the error
message would fail.

PR-URL: nodejs#19177
Refs: nodejs#19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
joyeecheung added a commit to joyeecheung/node that referenced this pull request Jun 13, 2018
Create `lib/internal/bootstrap/` and put bootstrappers there:

Before:

```
lib/internal
├── ...
├── bootstrap_loaders.js
└── bootstrap_node.js
```

After:

```
lib/internal
├── ...
└── bootstrap
    ├── loaders.js
    └── node.js
```

PR-URL: nodejs#19177
Refs: nodejs#19112
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
BridgeAR added a commit to BridgeAR/node that referenced this pull request Feb 22, 2019
The current caching logic broke by [0] because it used destructuring
on the module arguments. Since the exported property is a primitive
counting it up or down would not have any effect anymore in the module
that required that property.

The original implementation would cache all stat calls caused during
bootstrap. Afterwards it would clear the cache and lazy require calls
during runtime would create a new cascading cache for the then
loaded modules and clear the cache again.
This behavior is now restored. This is difficult to test without
exposing a lot of information and therfore the existing tests have
been removed (as they could not detect the issue).

With the broken implementation it caused each module compilation to
reset the cache and therefore minimizing the effect drastically.

[0] nodejs#19177
BridgeAR added a commit to BridgeAR/node that referenced this pull request Mar 1, 2019
The current caching logic broke by [0] because it used destructuring
on the module arguments. Since the exported property is a primitive
counting it up or down would not have any effect anymore in the module
that required that property.

The original implementation would cache all stat calls caused during
bootstrap. Afterwards it would clear the cache and lazy require calls
during runtime would create a new cascading cache for the then
loaded modules and clear the cache again.
This behavior is now restored. This is difficult to test without
exposing a lot of information and therfore the existing tests have
been removed (as they could not detect the issue).

With the broken implementation it caused each module compilation to
reset the cache and therefore minimizing the effect drastically.

[0] nodejs#19177

PR-URL: nodejs#26266
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax pushed a commit that referenced this pull request Mar 1, 2019
The current caching logic broke by [0] because it used destructuring
on the module arguments. Since the exported property is a primitive
counting it up or down would not have any effect anymore in the module
that required that property.

The original implementation would cache all stat calls caused during
bootstrap. Afterwards it would clear the cache and lazy require calls
during runtime would create a new cascading cache for the then
loaded modules and clear the cache again.
This behavior is now restored. This is difficult to test without
exposing a lot of information and therfore the existing tests have
been removed (as they could not detect the issue).

With the broken implementation it caused each module compilation to
reset the cache and therefore minimizing the effect drastically.

[0] #19177

PR-URL: #26266
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
esm Issues and PRs related to the ECMAScript Modules implementation. lib / src Issues and PRs related to general changes in the lib or src directory. module Issues and PRs related to the module subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants