file.path is only a getter

Version

23

Platform

This is going to break every library I have that uses `fs.readdir` with `withFileTypes`:


      file.path = path.join(dir, file.name);
               ^
TypeError: Cannot set property path of #<Dirent> which has only a getter


The `file.path` property is everywhere in my code, it represents `path.join(dir, file.name)`, which is the full path to the file. This is how millions of projects are using that property already, and it's decorated (in my code) onto the file object returned by `withFileTypes`.

Subsystem

No response

What steps will reproduce the bug?

fs.readdirSync(__dirname).map(f => {
  f.path = path.join(__dirname, f.name)
})

How often does it reproduce? Is there a required condition?

Since withFileTypes has been around for years, this will happen with every library that I created that uses withFileTypes.

What is the expected behavior? Why is that the expected behavior?

file.path should be the absolute path to the file if it's going to be decorated, since this is a well established convention for every file and path library I've ever seen.

What do you see instead?

I see an error with a read only property, and a warning that path is deprecated. I have to say this is completely absurd. parentPath? Since node has existed dirname has been the name of directories.

Why is someone deciding to name it parentPath? Who made this decision? Is there a precedent for this or a spec you can point to? FWIW I've created hundreds of path libraries and I have never seen that term used anywhere.

Additional information

I think whoever is making these decisions should be involving people with more experience in Node.js. These decisions are going to cause massive headaches for existing code that use firmly establish conventions that have existed for years.

If you're going to finally fix file/dirent objects to be more useful, why not just use conventions of tooling that has already proliferated in the ecosystem, like vinyl files? I'm really interested in the reasoning here.

This is by-design. dirent.path is deprecated, and according to the documentation, it is a read-only property.

https://nodejs.org/api/fs.html#direntpath states:

Alias for dirent.parentPath. Read-only.

Sorry for the close/reopen, 😅 butter-fingers...

I think whoever is making these decisions should be involving people with more experience in Node.js.

The PR to (runtime) deprecate this (#51050) was open for over five months before merging. There was plenty of opportunity for feedback during that time. You can always open a PR requesting a change (though it may have to wait until after the deprecation cycle).

If you're going to finally fix file/dirent objects to be more useful

If you have advice for it to be more useful, I'm sure you can open a feature request.

Additionally, your issue isn't very clear, which of the following are you asking:

Why is it only a getter?

The property is defined as read-only. This is not a bug.

Why was it deprecated?

Feel free to search past issues, such as #50976 for more context

Why isn't it XYZ?

If you'd like to see a change, open a feature request or PR.

Assuming that the intent of this issue was (1) Why is it only a getter, I've marked this was wontfix, as the getter is by design.

The property is defined as read-only. This is not a bug.

It should be. My packages represent about 10% of the downloads in Node.js and this will break my packages.

@aduh95

cc @aduh95

You can do Object.defineProperty() to not hit the getter error. If you're interested in the history of .path and .parentPath on Dirent class, you can find the context in the PRs that introduced them.

@doowb

You can do Object.defineProperty() to not hit the getter error. If you're interested in the history of .path and .parentPath on Dirent class, you can find the context in the PRs that introduced them.

Thanks for explaining how javascript properties work. I'm not interested in the discussions at all. If I read the discussions, will I find invitations to people like me, @doowb, @phated, or other people who have created the most used path/file related projects in Node.js? I don't remember receiving any invites to the discussion, or any discussion about similar topics, yet my packages account for almost 10% of Node.js total downloads, and some of my packages have more than 30 million dependents. IMHO that makes no sense at all, but I can live it it.

What I am interested in, is not having to deal with my already existing packages breaking when people start using the latest version(s) of Node.

A simple search shows that 148,000 javascript files, and 53,000 typescript files on GitHub use the exactly term: file.path. At least 1,000 of those are directly using withFileTypes in that specific file, and surely many of those references are also using Dirent but not directly in that file. More importantly, there are countless other ways to define that property: f, dirent etc etc. so it's likely that there are many other files doing the same.

Why is this even a debate. Node should have been using symbols or something if you want the ability to arbitrarily change properties. This is unacceptable. Please either make path writable or revert this change. You're not the one that has to deal with the consequences of this change. This was a bad decision, and it needs to be reverted. You can't just make a very common property read-only on an object that users have been able to decorate for years.

I don't remember receiving any invites to the discussion, or any discussion about similar topics, yet my packages account for almost 10% of Node.js total downloads, and some of my packages have more than 30 million dependents. IMHO that makes no sense at all, but I can live it it.

I can see why you are upset, and I have been similarly been upset in the past. The only way to be sure to be part of the discussion is to show up, and devoting effort and care to the project. It still happens from time to time to me as well that a change that affects my projects badly gets landed, and I’m on the TSC. The only solution is to show up, and this is on each of us.

What I propose:

we revert the breakage for v23
you send a few of your modules to be included in CITGM, so we can check them before every release (this has some responsibility on your end
we assess if we still want to make this deprecation and how.

@jonschlinkert

@jonschlinkert, which modules did it break?

It should be. My packages represent about 10% of the downloads in Node.js and this will break my packages.

I was saying it would break them when people start using the latest. Fortunately I haven't gotten issues yet

First of all I truly love your work, but when you make claims like this, it diminishes some of that respect and credibility, at least in my opinion.

I think whoever is making these decisions should be involving people with more experience in Node.js.

This is also an intriguing point: who is actually more qualified to be experienced, and who can confidently make that claim?

First of all I truly love your work, but when you make claims like this, it diminishes some of that respect and credibility, at least in my opinion.

My point was that this wasn't a theoretical scenario and that I have first-hand knowledge that this will break some of my packages. And given the number of other projects that depend on my packages, this breakage should be considered a bug. If you don't use real world usage or regressions to decide what is a bug and what isn't, then what is your yardstick? If you took that statement to mean something else, that was not my intent.

I can see how you might have thought I intended my comment differently, but that's not where my mind was.

fs: make `dirent.path` writable

@tomweptinstall

@tomweptinstall

First of all I truly love your work, but when you make claims like this, it diminishes some of that respect and credibility, at least in my opinion.

FWIW I know @jonschlinkert really well and he didn't mean for his comment to come across the way you may be taking it.

fs: make `dirent.path` writable

This is fixed and will be released in the next v23 release

thank you!!!

Navigation Menu

Repository navigation

file.path is only a getter #55538

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

file.path is only a getter #55538

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Activity

avivkeller commented on Oct 25, 2024

avivkeller commented on Oct 25, 2024

jonschlinkert commented on Oct 25, 2024

marco-ippolito commented on Oct 25, 2024

aduh95 commented on Oct 25, 2024

jonschlinkert commented on Oct 25, 2024

mcollina commented on Oct 25, 2024

mcollina commented on Oct 25, 2024

8 remaining items

tomweptinstall commented on Oct 27, 2024

jonschlinkert commented on Oct 27, 2024

doowb commented on Oct 28, 2024

mcollina commented on Nov 8, 2024

jonschlinkert commented on Nov 8, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions