pnpm support

[brettz9]

Any chance you could add pnpm support? I save so much hard-drive space with all my projects by using pnpm, so it'd be nice to get the benefits of your project on my pnpm projects.

[chase-moskal]

@brettz9 very interesting — i'm uninitiated about pnpm — for importly to support it, i'm unsure about what changes need to be made?

importly operates by reading a package-lock.json.

• importly can alternatively read a package.json (or any json that has the dependencies field)
• however, reading from a package-lock.json is much preferable, as it has the additional information importly needs to properly scope subdependencies (so that dependencies can use different versions of the same subdependencies)

if your pnpm projects have a package-lock.json for importly, then i suspect that importly might work as-is.

it may be worth noting that

• by default, importly also reads the package.json for each dependency by looking in your local node_modules.
• if this causes an issue with pnpm (if perhaps the node_modules structure is different under pnpm), you can set importly's option --lookup=unpkg to instruct importly to find this information on the web, rather than by reading from node_modules.

let me know if this helps, or if you're having issues running importly in your pnpm projects, or if importly requires some changes to become compatible.

👋 🍺

[brettz9]

Hi,

@brettz9 very interesting — i'm uninitiated about pnpm — for importly to support it, i'm unsure about what changes need to be made?

pnpm indeed follows a different difrectory structure than npm: https://pnpm.io/motivation (see also the links on the page).

I haven't explored it deeply enough to know how it might be done, but:

1. pnpm creates its own format of lock file, pnpm-lock.yaml. Here's an example file: https://github.com/dragfyre/bahai-date-api/blob/master/pnpm-lock.yaml

2. It's in the YAML format, but there should be parsers available to help with this format if necessary.

3. But since pnpm uses a content-addressable storage which doesn't directly point to specific file locations (e.g., node_modules is not found anywhere in the file), I guess one might just need to know pnpm's approach and/or use the lock file to find out where it should be.

importly operates by reading a package-lock.json.

• importly can alternatively read a package.json (or any json that has the dependencies field)
• however, reading from a package-lock.json is much preferable, as it has the additional information importly needs to properly scope subdependencies (so that dependencies can use different versions of the same subdependencies)

if your pnpm projects have a package-lock.json for importly, then i suspect that importly might work as-is.

No, as per above, they use their own lock files, along with saving to different locations (though still respecting Node's resolution algorithm).

it may be worth noting that

• by default, importly also reads the package.json for each dependency by looking in your local node_modules.
• if this causes an issue with pnpm (if perhaps the node_modules structure is different under pnpm), you can set importly's option --lookup=unpkg to instruct importly to find this information on the web, rather than by reading from node_modules.

Ok, good to know. Still, if it could be done in a way that is aware of pnpm this might still be ideal (especially as more of us concerned with hard drive space may also be on slower connections).

let me know if this helps, or if you're having issues running importly in your pnpm projects, or if importly requires some changes to become compatible.

Thanks for the info... However, it seems I won't be able to get the subdependencies since I still apparently need to supply a package-lock.json to get them (and pnpm doesn't create such a lock file). I tried running npm i --package-lock-only to see if I could supply that without overwriting my directory structure, but it nevertheless seemed to traverse the local directory structure (I saw .pnpm paths in the logging) and got an unclear npm error at the end (" Cannot read property 'matches' of null"). If I were to reinstall temporarily to get a package-lock, the directory structure will no longer be identical for the purposes of the import maps when switching back to reinstall by pnpm).

Btw, FWIW, came across one other use case for your tool besides for direct browser usage--template libraries which wish to allow Node resolution within evaluated client-side templates without forcing the browser to traverse node_modules to find them.

Best wishes...

[chase-moskal]

@brettz9 thanks for the detailed info!

if i'm understanding this right, to add pnpm support,

• we'd need to implement pnpm-lock.yaml support into importly's parse function
  • we'd add PnpmLockYaml as an enum value to InputType in types.ts
  • we'd surely want to add a new utility function read-pnpm-lock-yaml.ts, which would be very similar in implementation to read-package-lock-json.ts
• at first glance, it looks to me like pnpm-lock files are similar enough to package-lock files for this to be straightforward
• it seems to me like this new pnpm support would not need any new options or flags for the importly cli, and there's no breaking change for downstream importly users

I'd be happy to collaborate here and merge a pull request, though i personally don't have time now to do the implementation. if you'd like to chat in realtime, you can ping me in this discord group, i'd be happy to be of assistance.

Btw, FWIW, came across one other use case for your tool besides for direct browser usage--template libraries which wish to allow Node resolution within evaluated client-side templates without forcing the browser to traverse node_modules to find them.

very fascinating, i'd love to learn more about this use-case, especially if we can improve importly for the purpose

🍻 cheers!