this is what i was looking for (requests)

hey this sounds great. i havent tested it yet but it sounds like its going to solve what ive been dealing with unless it has any major issues.

if it ends up working for me i might even myself update it but here are some things that are unnecessary

currently i see the boilerplate in the .cjs config just some redundant jumble i need to look up online everytime to get right when it serves no purpose.
why not simplify it down to the same syntax .env files use. call it physical.env or physical-link.env and simply put dependencies like
dep1=/path/to/dep

next up when linking from physical link installed globally. we should also shorthand the cmd to physical-link /path/to/physical.env when doing so at root of project when there is no need to specify both project and config.

i have some questions like does npm install overwite changes and such and i will find out.

[everdimension]

Hi! Thank you for your feedback!

simply put dependencies like
dep1=/path/to/dep

I like how this looks, but I'm not familiar with any javascript tooling projects that use <name>.env file for configuration 🤔
My motivation for a dedicated "manifest" field is to be able to add other behavioral options later.
As for module.export = part, this isn't required if you use .json format for the config:

{
  "manifest": {
    "my-dependency": "~/my-dependency",
    "another-dependency": "../another-dependency"
  }
}

we should also shorthand the cmd to physical-link /path/to/physical.env when doing so at root of project when there is no need to specify both project and config.

I believe this is how it works now. When you have a config file in project root, simply running npx physical-link (or just physical-link if you installed it globally) should be sufficient

My motivation for a dedicated "manifest" field is to be able to add other behavioral options later.

What options did you have in mind? may i ask

I believe this is how it works now. When you have a config file in project root, simply running npx physical-link (or just physical-link if you installed it globally) should be sufficient

This is not what i meant. I manage multiple projects and don't see any benefit to adding just another config to every project root that isnt going to get shared with anyone else and i have to add entries to every gitignore and npmignore and it gets lost if i reclone. We should always minimize the contents of a project if we can to keep it as simple as possible. I think it would make a lot more sense to keep shared configs for projects i manage externally and when needed i can physical-link external/path at the root of any repo.

This is what readme shows and it requires 2 pastes and memorization of --config and --project for hooking up every single dir and i am certain i will forget the words --project and --config everytime physical-link --config ~/path/to/your/global/config --project ~/path/to/your-app

also, it would be even cooler if you could skip the config creation alltogether and physical-link /local/npm/package at root of projects to have a config (at root or global) automatically generated, this way you can keep the longer config syntax and allow for more options but it gets autogenerated so it doesnt matter. and as you physical-link more packages it gets appended to config.

• so basically, .json manifest scaffolding can stay if you want to allow auto generation. no one is going to remember the syntax otherwise.

• considerably simplify the CLI to its simplest form. physical-link alone works as expected. naturally append /local/npm/path to hook 1 package. or naturally append /global/config/path to hook global config. you introduce config creation.and effectively remove all memorization overhead from the project. thoughts?

@everdimension