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

internal: lazy load fs due to circular dependency #11260

Closed
wants to merge 1 commit into from

Conversation

evanlucas
Copy link
Contributor

@evanlucas evanlucas commented Feb 9, 2017

The fs module requires internal/fs and internal/fs requires fs which
causes a circular dependency. This change lazy loads fs inside of
internal/fs to prevent assertEncoding from breaking when requiring via
stdin.

Fixes: #11257

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

internal/fs

@nodejs-github-bot nodejs-github-bot added the fs Issues and PRs related to the fs subsystem / file system. label Feb 9, 2017
const path = require('path');

if (common.isWindows) {
common.skip('Skipping test on windows');
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe include why it's being skipped? I don't know if we usually do that or not...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yea, as of right now, I just don't know how to reproduce on windows and I don't have access to a windows box.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll spend a bit trying to reproduce on windows and if I can't, I'll update the message

`echo "require('${filename}')" | ${bin} &> ${out} || cat ${out}`;

const result = execSync(cmd).toString();
assert.strictEqual(result.includes('assertEncoding is not a function'),
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there anything we can explicitly detect? I'm just worried that if assertEncoding were to change names and a regression occurred, this wouldn't detect it.

Copy link
Contributor Author

@evanlucas evanlucas Feb 9, 2017

Choose a reason for hiding this comment

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

hm, maybe we can make the require console.log something instead? I'll see if I can come up with a better way of verifying the behavior. Good call :]

@jasnell
Copy link
Member

jasnell commented Feb 9, 2017

Another way of fixing this would be to move the implementation of writeSync() into the internal/fs module so that internal/fs does not require the circular dependency in the first place. The fs module can reexport it. Obviously that would be a bigger change that may require a bit more shifting around but it would ensure that we don't have to jump through these kinds of hoops

The fs module requires internal/fs and internal/fs requires fs which
causes a circular dependency. This change lazy loads fs inside of
internal/fs to prevent assertEncoding from breaking when requiring via
stdin.

Fixes: nodejs#11257
@evanlucas
Copy link
Contributor Author

@jasnell true, but at the same time, aren't we deprecating that? I'm also not sure how much sense it makes to move the implementation of fs.writeSync() and fs.closeSync() into internal. They are exposed and public api... seems like a little too much indirection in the code base IMO?

@jasnell
Copy link
Member

jasnell commented Feb 17, 2017

deprecating fs.writeSync() ? Not that I'm aware of.

The justification for moving them to internal would be precisely to avoid this kind of circular dependency and the need to lazy load at all. Just my opinion tho :-)

@evanlucas
Copy link
Contributor Author

@jasnell sorry for not being clear. I meant aren't we deprecating SyncWriteStream?

@jasnell
Copy link
Member

jasnell commented Feb 17, 2017

That's different. SyncWriteStream is only used when setting up process.stdout and process.stderr. It's wholly separate from fs.writeSync()

@TimothyGu
Copy link
Member

@evanlucas, any updates on this?

@evanlucas
Copy link
Contributor Author

@jasnell I have opened #11986 as you have suggested as an alternative.

@BridgeAR
Copy link
Member

I think this could be closed in favor of the new PR?

@jasnell
Copy link
Member

jasnell commented Aug 29, 2017

I believe it can be.

@jasnell jasnell closed this Aug 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fs Issues and PRs related to the fs subsystem / file system.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

stderr redirection breaks require
7 participants