feat: return path as name for root directories

[Sebastian-Webster]

What/Why

Previously, name-from-folder would return an empty string when passing in a root directory path (Linux/macOS: / and Windows: {A-Z}:\).

With this PR, instead of returning an empty string, it now returns the path for the directory as the name

References

This change is required for npm/cli#7038 to work.

EDIT: Linked to npm/cli PR

[wraithgar]

Fun fact: removing ternary operators is a good way to get on my good side ;)

[Sebastian-Webster]

Good to know ;)

[wraithgar]

The package name at the root should be empty. Returning the path is incorrect. Your package name is not "/" nor is it "C:\"

[wraithgar]

Can you show where this is blocking npm/cli#7038? That isn't apparent to me.

[Sebastian-Webster]

Can you show where this is blocking npm/cli#7038? That isn't apparent to me.

Sure :). As far as my understanding goes, the buildIdealTree method in workspaces/arborist/lib/arborist/build-ideal-tree.js creates an idealTree tracker with no subsection or key, and then #buildDeps in the same file creates an idealTree tracker with a subsection tree.name and an empty string for the key.

The tree.name part comes from the constructor for the Node class in workspaces/arborist/lib/node.js.
Assuming the path you are trying to run npm install at is E:\test, this.name would be set to the name parameter, but name is undefined so it gets the name from @npmcli/name-from-folder (which in this example would return test) and that becomes the value of this.name. In the #buildDeps method in build-ideal-tree a tracker would be created with the subsection being test.

Assuming the path you are trying to run npm install at is E:\, the name parameter in the constructor function is still undefined so it tries getting the name from@npmcli/name-from-folder. The name from folder would be an empty string, and since that is falsey it'll try to get the name from pkg.name. pkg is an empty object in this case, and therefore pkg.name is undefined. Undefined is falsey so it'll make this.name be null. That would make the #buildDeps method try to create an idealTree tracker with subsection null, but the buildIdealTree method has already made an idealTree tracker, so an error is created saying npm ERR! Tracker "idealTree" already exists

The package name at the root should be empty. Returning the path is incorrect. Your package name is not "/" nor is it "C:"

My way to resolve the issue above was to have @npmcli/name-from-folder return the path for root directories since they have no name so then tree.name wouldn't be null and an idealTree tracker could be created. Since that is incorrect behaviour, would it be alright to move the root directory logic to the Node class constructor so this.name would be set to the root directory path if path is a root directory? I wouldn't think it would create any conflicts since slashes can't be used in package names.

[wraithgar]

I think you're beginning to see why root packages are not allowed. Is the problem you're trying to solve so much of an issue that we have to refactor major parts of npm now? npm has never allowed root directories to be packages. Environments like docker solve this by putting things in a subdirectory first, which is pretty standard at this point.

I'm hesitant to go down this path, frankly. I think this is a good restriction and keeps a lot of odd (and maybe even potentially dangerous) setups from happening.

[Sebastian-Webster]

I agree that for macOS and Linux it wouldn't make sense to installing packages in a root directory, but in Windows (excluding the boot drive) it could make some slight sense for installing in the root directory for external drives if the only thing you want on your drive is a JS project. I could make root directory installs only allowed on Windows on drives other than C if your worry is with root directories for boot drives, but if root directory installs shouldn't be allowed regardless of what drive it is being installed in I could remove all of the changes for root installs. The current behaviour of installing packages in a root directory is throwing an error (mkdir error on Windows and Tracker "idealTree" already exists. error in macOS and Linux), and if root directory installs should not be allowed, I think it would be more helpful to the user to show an error saying that root directory installs are not allowed and they should create a subdirectory first. With the current behaviour it is hard to tell how to fix the problem and what the problem is.
I'll close this pull request because even if root directory installs should be allowed for Windows drives that aren't C I've found a way that could achieve that in the main cli repository with a one-line change so this pull request will no longer be needed regardless.