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