[Feature Request] Package.json Root / Base Directory

[oleersoy]

https://stackoverflow.com/questions/51313753/npm-package-json-base-root-property?noredirect=1#comment89604253_51313753

[mscdex]

Posting a link as the entirety of an issue submission is not very helpful, especially if the link in question becomes invalid at some point. Can you please elaborate here instead?

[oleersoy]

Sure.

It would be nice if there was a package.json property that can be used to specify the root folder that module resolution should start from. This would be follow the same metaphor as the html base element or the baseUrl in Typescripts tsconfig.json.

For example suppose we have an install in node_modules/mypackage/src/file1. And all the files we want to import start under the src directory. If we could specify something like:

 { 
    root: ./src/
 }

We could then require('mypackage/file1');

This eliminates the need to compile typescript into a different folder and then copy the package.json file into that folder.

[patrickroberts]

If a consumer of your package decides they want to import, say, your package.json with require('mypackage/package.json'), wouldn't this additional layer of indirection make things unnecessarily difficult and confusing? I also don't think this is a good idea, as this concept is a breaking change that package managers will have to implement in coordination in order to resolve an added layer of indirection to files for build processes, tests, and other automated scripts, that are already confusing enough.

[oleersoy]

If a consumer of your package decides they want to import, say, your package.json with require('mypackage/package.json'), wouldn't this additional layer of indirection make things unnecessarily difficult and confusing?

No you would still do that exactly the same way you are doing it now.

I also don't think this is a good idea, as this concept is a breaking change that package managers will have to implement in coordination in order to resolve an added layer of indirection to files for build processes, tests, and other automated scripts, that are already confusing enough.

This is independent of package managers. Package managers are responsible for downloading a package and managing dependencies correspondingly. All this does is allow the package.json specification to tell Node that it should start looking to resolve packages from a sub directory of the package instead of the immediate package root.

For example right now if we do:

import { $ } from '@dollarsignpackage/folder/dollarsignmodule.ts`;

Node expects the package structure to be laid out like this:

node_modules/@dollarsignpackage/folder/dollarsignmodule.ts.

So developers usually create a dist folder to create this exact structure, which includes copying over the package.json file, etc. If Node had the root or base property option we could just set that and node would resolve from that directory instead.

So for example if the folder/subfolder folders are located in a dist folder we could just set root: dist, and then node would automatically resolve from dist/folder/dollarsignmodule.ts. It should be a fairly trivial change to the module resolver. Browsers already do this with the base element.

[Trott]

It should be a fairly trivial change to the module resolver.

If it is truly a trivial change, it might be easier to reason about this and discuss it if it's a pull request. A test using stub modules you create in the test/fixtures directory might uncover unforeseen issues or lay to rest incorrect ideas about problems this might cause.

For reasons that I hope are easy to understand, a lot of core devs are exceedingly reluctant to see anything change in the module resolver unless absolutely necessary, so please expect lots of questions.

I know you were just throwing out a possible syntax and not the required syntax, but root might be a problematic name if there are any significant packages in the ecosystem that are already using it for something. Just a note of something to consider; not saying it's a reason we can never do anything like this.

[ljharb]

cc @nodejs/modules

[ljharb]

Unless CJS has a way to designate "not the root of the package" as the root dir for resolution, I don't think it would be appropriate for ESM (or WASM, or any other future module type) to have that capability.

[richardlau]

Unless CJS has a way to designate "not the root of the package" as the root dir for resolution, I don't think it would be appropriate for ESM (or WASM, or any other future module type) to have that capability.

Node.js has no concept of packages (at least in CJS)(note that a package is not the same as a module). Currently the only field in package.json that Node.js even looks at is main -- I don't think it makes sense to extend this especially if it doesn't suit ESM.

[ljharb]

@richardlau right - i'm suggesting that node could look at an additional field to set the directory that all requires of the package resolve relative to - and if that feature existed for CJS, it would also hopefully work for ESM (and it would make sense for both).

[oleersoy]

Another idea would be to allow main to be a directory, or allow the file that main points to to point to a directory. That way we don't really change anything WRT to how any current node package works, but it still satisfies the use case.

[devsnek]

i think this would be better suited in ESM as a resolve hook.

what if cjs could resolve the current package it was in? e.g. your package is named 'X' so you do require('X/y/z');

[oleersoy]

@richardlau right - i'm suggesting that node could look at an additional field to set the directory that all requires of the package resolve relative to - and if that feature existed for CJS, it would also hopefully work for ESM (and it would make sense for both).

Yes it should work for anything (CSS, json, xml, ESM, ...). For example suppose we had a project with all sorts of resources that needed to be compiled and it had source with main and test directories setup like this:

src/main/css
src/main/xml
src/main/json
src/main/svg

src/test/json
src/test/svg
src/test/typescript

And all of these were compiled into a target folder like this:

target/main/css
target/main/js
target/main/xml
target/main/json
target/main/svg

target/test/json
target/test/svg
target/test/typescript

And now we wish to load package resources that have been distributed to NPM. So lets call the package @resources and set the main attribute to target/main.

...
"main": "target/main/"
...

This is the location that all the resources have been compiled to.

We do npm i -S @resources. Then load any resource from target/main with a statement like require('@resources/xml/customers.xml');

Node would then resolve the path @resources/xml/customers.xml into node_modules/@resources/target/main/xml/customers.xml.

[ljharb]

The more common case (not xml, svg, or css) would be "i have all my code in src/ and i transpile it using babel to lib/, but now all my consumers have to deep-require foo/lib/blah instead of just foo/blah".

This feature would allow any package using babel to support cleaner deep requires.

[oleersoy]

I think that the total impact would make economic sense as well as far as developer efficiency goes. For example projects like RxJS remap all compiled resources into a directory structure that is different from what we see on Github.

Personally when I need to see the source, I like to open the node_modules folder in VSCode and add logging statements etc. If I could recompile the code right there and have it it work instantly that would be a big performance boost. I no longer have to got back to the original source and recompile and reinstall and what since what I'm looking at in node_modules is essentially a mirror of the github repository, I no longer have to do a bunch of mental remapping gymnastics ... this extends to every single project that is currently remapping resources in order to be able to publish them.

[ljharb]

@oleersoy for the record, you can already do that, unless the package has gone out of its way to exclude their raw source from the npm package.