Skip to content

Add way to stop the module resolution at a specific directory #43368

Description

@tmtron

What is the problem this feature will solve?

Currently the node resolution will traverse all the way up to the root of the file-system.

It would be great to have a way to stop the resolution at a specific directory.

There are different use-cases that could benefit from this

  • monorepos with package.json files at different levels
    • e.g. a nested project that has it's own package.json file may wish to only use dependencies in this project to make sure, that no other dependencies are used by accident
    • Related Stackoverflow Question
  • some tools output artifacts to a dist directory which may include a separate node_modules folder (with only the packages that are required for production)
    • the whole dist directory is meant to be self-contained: i.e. we can copy the dir to another PC and just start the app
    • during development developers will just start the app from their dist directory to see if it works
      • again, this can work by accident: when a required package is missing from .dist/node_modules, node might find it in ./node_modules

What is the feature you are proposing to solve the problem?

Not sure what the best way is. Here are some thoughts:

  • Maybe add a new property to package.json: e.g. resolutionRoot: true
    Then nested packages could directly use this. And for the dist-use case, the build-process can create a package.json file in the dist directory
  • or maybe this should be another file - different to package.json
  • or use an environment variable instead
  • or a cmd-line argument for node, ..

What alternatives have you considered?

Currently we copy the whole folder and subfolders to the root of the file-system and start the app from there: then the node-resolution will for sure not find additional node_module folders.

Cons:

  • copying takes time and space
  • the directories are not deleted automatically
  • when we have many projects, the file-system is cluttered up

Activity

  1. Trott commented on Jun 10, 2022

    @Trott
    Member

    Duplicate of #43192?

  2. Trott commented on Jun 10, 2022

    @Trott
    Member

    @nodejs/modules

  3. tmtron commented on Jun 10, 2022

    @tmtron
    Author

    Duplicate of #43192?

    I've seen this issue before. I think it's related, but not exactly a duplicate. My intent is not related to security at all - only to improve the development process.

  4. GeoffreyBooth commented on Jun 10, 2022

    @GeoffreyBooth
    Member

    This is already possible via loaders: https://nodejs.org/api/esm.html#resolvespecifier-context-defaultresolve. I don’t think Node will likely support any other ways of customizing resolution, as there are too many potential preferences to consider. The resolve hook allows you to write your own resolution algorithm if you’d prefer behavior different from Node’s default.

  5. added a commit that references this issue on Jul 13, 2022
  6. arhart commented on Jul 23, 2022

    @arhart
    Contributor

    @tmtron if an environment variable or command line argument meets your need, would a policy like the following do what you want, placed in the dist directory and loaded with --experimental-policy? Alternatively placed somewhere else with the path adjusted accordingly.

    {
      "scopes": {
        "./": {
          "integrity": true,
          "dependencies": true
        }
      }
    }
    
  7. arhart commented on Jul 23, 2022

    @arhart
    Contributor

    NODE_OPTIONS can be set if an environment variable would be more convenient.

  8. tmtron commented on Jul 25, 2022

    @tmtron
    Author

    @arhart Thanks, that seems to work.

    • in my dist directory
      • I create the policy.json file:
        {
          "scopes": {
            "./": {
              "integrity": true,
              "dependencies": true
            }
          }
        }
      • I also need a package.json file (can be empty)
      • then start the application with: node --experimental-policy=policy.json main.js

    I'll close this issue in favour of #43192 and #43828

  9. GeekyEggo commented on Jun 1, 2024

    @GeekyEggo

    With policies now marked as deprecated, is there an alternative approach to achieving the above solution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestIssues requesting new Node.js features.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions