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

fs: move SyncWriteStream to internal/fs #6749

Closed
wants to merge 1 commit into from

Conversation

jasnell
Copy link
Member

@jasnell jasnell commented May 13, 2016

Checklist
  • tests and code linting passes
  • documentation is changed or added
  • the commit message follows commit guidelines
Affected core subsystem(s)

fs

Description of change

Move the internal SyncWriteStream class to internal/fs. This pulls it off require('fs') without a deprecation. It was always intended to be private, says that it's private in the source and tells people not to use it.

Update the impl a bit while we're at it to use class instead of util.extends

@jasnell jasnell added the fs Issues and PRs related to the fs subsystem / file system. label May 13, 2016
@jasnell
Copy link
Member Author

jasnell commented May 13, 2016

@@ -131,7 +131,7 @@ function createWritableStdioStream(fd) {
break;

case 'FILE':
var fs = require('fs');
var fs = require('internal/fs');
Copy link
Member

Choose a reason for hiding this comment

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

const?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'd rather not in this PR. There are several similar updates that can be made elsewhere in this file that should be done in a separate PR

@ChALkeR ChALkeR added the semver-major PRs that contain breaking changes and should be released in the next major version. label May 14, 2016
value: SyncWriteStream
get: util.deprecate(
() => { return _syncwritestream; },
'fs.SyncWriteStream is deprecated.'),
Copy link
Member

Choose a reason for hiding this comment

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

perhaps and will be removed soon/in Node.js v***?

Copy link
Member

@ChALkeR ChALkeR May 15, 2016

Choose a reason for hiding this comment

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

Because domain and fs.existsSync are also deprecated 😉.

Copy link
Member Author

Choose a reason for hiding this comment

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

Perhaps just will be removed soon without a firm version.

@jasnell
Copy link
Member Author

jasnell commented May 15, 2016

@nodejs/ctc ... Tagging as ctc-agenda because it's (a) a semver-major and (b) requires a deprecation. I don't think this one is particularly controversial tho.

@rvagg
Copy link
Member

rvagg commented May 15, 2016

+1, but only after a full deprecation cycle

@ChALkeR
Copy link
Member

ChALkeR commented May 15, 2016

Ah, also +1 from me (with a deprecation cycle).

https://gist.github.com/ChALkeR/f2cb74429769e91752d4b7f41b70dda2.SyncWriteStream usage.

I'll copy my comment from a note above:

  • debug just copied a part of Node.js code, and acknowledges that it's a hack: https://github.com/visionmedia/debug/blob/master/node.js#L137-L142.

    I reported an issue there.

  • mock-fs does Node.js version detection and includes a per-major-version copy of the internal fs module (presumeably patched). We can ignore that.

  • I suspect some sort of automatic deps packaging for browser as the main culpit for most of the other cases. meteor-please-and-thank-you, for example, has pakmanaged.js which was created by pakmanager and actually includes debug sources. jscs was browserified and also includes debug sources.

@jasnell
Copy link
Member Author

jasnell commented May 15, 2016

The deprecation is in there now. Just squashed the commits down.
New CI: https://ci.nodejs.org/job/node-test-pull-request/2649/
CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/thealphanerd-smoker/267/

@jasnell
Copy link
Member Author

jasnell commented May 16, 2016

CI is green.
CITGM is green except for known unrelated failure.

@MylesBorins
Copy link
Member

MylesBorins commented May 16, 2016

@jasnell that serialport failure on ppc is new... rerunning on master to double check

edit: looks like there was an update to serialport that may have broken this

@jasnell
Copy link
Member Author

jasnell commented May 16, 2016

hmm... I've seen that serialport failure before. I believe I was running citgm locally tho.


// Change strings to buffers. SLOW
if (typeof data === 'string') {
data = Buffer.from(data, encoding);
Copy link
Contributor

Choose a reason for hiding this comment

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

Note to self, this doesn't need to be done. But for future optimization.

@MylesBorins
Copy link
Member

MylesBorins commented May 16, 2016

A run on master has serialport tests passing on ppc

Here's another run of this pull's head just to make sure it wasn't a one off: https://ci.nodejs.org/view/Node.js-citgm/job/thealphanerd-smoker/269/

edit: was green this time... ¯_(ツ)_/¯

@ronkorving
Copy link
Contributor

Happy to see this out of fs.js, LGTM.

@ChALkeR
Copy link
Member

ChALkeR commented May 18, 2016

This is blocked by #6413, btw. I mean — merging this will obviously break reevaluating fs module sources and old graceful-fs versions, so we should make sure that we are fine with that first.

@ChALkeR ChALkeR added the blocked PRs that are blocked by other issues or PRs. label May 18, 2016
@jasnell
Copy link
Member Author

jasnell commented May 18, 2016

grrr... {I'm saying a few bad words silently to myself right now}... you're right tho @ChALkeR . Would very much like to get #6413 landed.

@chrisdickinson
Copy link
Contributor

I'm curious — aside from the comment that notes that it was supposed to be private, what's the reasoning behind making this private now? It seems like it might not be worth potentially breaking things to move this into internal — I don't think we see much support load for this API as it stands.

@jasnell
Copy link
Member Author

jasnell commented May 18, 2016

CTC discussion on this was to leave this open but hold off on landing until a later date after #6413 lands.

@targos
Copy link
Member

targos commented Sep 1, 2016

It's a semver-patch that depends on a semver-major, right? Adding the "dont-land" labels.

@jasnell
Copy link
Member Author

jasnell commented Sep 1, 2016

I believe so, yes, landing on v6 should be fine tho as I believe the semver-major landed there. Could be wrong.

@targos
Copy link
Member

targos commented Sep 1, 2016

The require('internal/fs'); makes it only landable on master I believe.

@jasnell
Copy link
Member Author

jasnell commented Sep 1, 2016

ah yes, because of the graceful-fs warning. You're right. That's fine, it wouldn't be critical to land this in v6 at all.

@jasnell
Copy link
Member Author

jasnell commented Sep 1, 2016

@targos ... other than the don't land labels, does this LGTY?

@jasnell
Copy link
Member Author

jasnell commented Sep 1, 2016

@ChALkeR ... does this still LGTY? The only change is that I removed the runtime deprecation

@ChALkeR
Copy link
Member

ChALkeR commented Sep 2, 2016

@jasnell, what does the «doc-only deprecation» mean here? It isn't documented =).

@jasnell
Copy link
Member Author

jasnell commented Sep 2, 2016

It just means adding the code comment that indicates the intention to
runtime deprecate in v8 or later.

On Friday, September 2, 2016, Сковорода Никита Андреевич <
notifications@github.com> wrote:

@jasnell https://github.com/jasnell, what does the «doc-only
deprecation» mean here? It isn't documented =).


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6749 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAa2eaDPBp4jLK60RFg20HMuI8DARqUYks5ql9qTgaJpZM4Iebtd
.

@ChALkeR
Copy link
Member

ChALkeR commented Sep 2, 2016

@jasnell What would be the difference to users between runtime deprecation in v7 and runtime deprecation in v8? Why do we prefer the latter?

@jasnell
Copy link
Member Author

jasnell commented Sep 2, 2016

Given the issues that have been caused by other runtime deprecations, and
given that there's no pressing need to runtime deprecate this, I'd prefer
to just space it out a bit more. There's no significant need to rush it.

On Friday, September 2, 2016, Сковорода Никита Андреевич <
notifications@github.com> wrote:

@jasnell https://github.com/jasnell What would be the difference to
users between runtime deprecation in v7 and runtime deprecation in v8? Why
do we prefer the latter?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6749 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAa2ebCRaRgxcHQ2eVTdRjhJzpYiEbYWks5qmBmSgaJpZM4Iebtd
.

@ChALkeR
Copy link
Member

ChALkeR commented Sep 2, 2016

@jasnell Ah, ok. LGTM. =)

@ChALkeR
Copy link
Member

ChALkeR commented Sep 2, 2016

@jasnell Perhaps that could be included into the release notes, for this and other «documentation-only» deprecations of undocumented functions.

@jasnell
Copy link
Member Author

jasnell commented Sep 2, 2016

+1 to adding it to the release notes.

Move the implementation of SyncWriteStream to internal/fs.
@jasnell
Copy link
Member Author

jasnell commented Sep 2, 2016

@jasnell
Copy link
Member Author

jasnell commented Sep 2, 2016

Some weird red in that last CI run... trying again: https://ci.nodejs.org/job/node-test-pull-request/3928/

@jasnell
Copy link
Member Author

jasnell commented Sep 2, 2016

@nodejs/build ... there's definitely something weird happening with arm in CI

@jasnell
Copy link
Member Author

jasnell commented Sep 2, 2016

Failures in CI are unrelated. Landing!

jasnell added a commit that referenced this pull request Sep 2, 2016
Move the implementation of SyncWriteStream to internal/fs.

PR-URL: #6749
Reviewed-By: Ron Korving <ron@ronkorving.nl>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
@jasnell
Copy link
Member Author

jasnell commented Sep 2, 2016

Landed in dc72779

@jasnell jasnell closed this Sep 2, 2016
@chadfurman
Copy link

How do we install "internal/fs" ?

npm/npm#14579

when I run npm install --save-dev internal/fs I get an error about my github keys and that I cannot read the remote repo. I'm generally getting errors about cannot find module internal/fs -- what's up here?

@sam-github
Copy link
Contributor

You don't install internal/fs, this is a bug in graceful-fs, sounds like.

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.

None yet