file.path is only a getter

[jonschlinkert]

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.

[avivkeller]

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.

[avivkeller]

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:

1. Why is it only a getter?

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

3. Why was it deprecated?

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

5. 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.

[jonschlinkert]

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.

[marco-ippolito]

cc @aduh95

[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.

[jonschlinkert]

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.

[mcollina]

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:

1. we revert the breakage for v23
2. 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
3. we assess if we still want to make this deprecation and how.

[mcollina]

@jonschlinkert, which modules did it break?