Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] emplace is triggered by non global npm #323

Open
jayvdb opened this issue Aug 10, 2022 · 6 comments
Open

[BUG] emplace is triggered by non global npm #323

jayvdb opened this issue Aug 10, 2022 · 6 comments
Labels
bug Something isn't working

Comments

@jayvdb
Copy link

jayvdb commented Aug 10, 2022

Describe the bug
emplace tries to record npm install occurring in local projects.

To Reproduce
Steps to reproduce the behavior:

  1. In a node project, type: npm install @nebular/theme @angular/cdk @angular/animations eva-icons @nebular/eva-icons @nebular/auth @nebular/security

Result:

Opening Emplace repo: "/home/jayvdb/.local/share/emplace".
Mirror this command?
- eva-icons (Node Package Manager)

Expected behavior
Nothing should happen unless -g is used

Desktop (please complete the following information):

  • OS: Linux
  • Shell: Bash

Additional context

Machine information

#### Software version

emplace 1.4.2 (v1.4.2-70-g3b2b6b1)

#### Operating system

Linux 5.18.12-1-default

#### Environment variables

```bash
SHELL=/bin/bash
EMPLACE_CONFIG=/home/jayvdb/.config/emplace.toml

Git version

> git --version 
git version 2.37.1

Compile time information

  • Profile: release
  • Target triple: x86_64-unknown-linux-gnu
  • Family: unix
  • OS: linux
  • Architecture: x86_64
  • Pointer width: 64
  • Endian: little
  • CPU features: fxsr,sse,sse2
  • Host: x86_64-unknown-linux-gnu
@jayvdb jayvdb added the bug Something isn't working label Aug 10, 2022
@tversteeg
Copy link
Owner

Hi @jayvdb, unfortunately I'm not maintaining this application anymore, so I won't pick up this issue. Any PR's are greatly appreciated though!

@tversteeg tversteeg removed their assignment Aug 11, 2022
@jayvdb
Copy link
Author

jayvdb commented Aug 15, 2022

I am happy to build the fix for this.

I've had a poke around, and notice the problem of local project package installs is unique to npm. All others are either global/system or per-user installs. Also none of the open issues are proposing another package manager which would have the same problem.

A quick fix is to change npm to be similar to rustup which has a sub_commands of "component add".

i.e. sub_commands for npm could be install -g and install --global. However that would not catch npm install foo -g / npm install foo --global.

To properly solve his without regressions, IMO the package managers need a member has_required_flag or similar, which for npm would return -g and --global. This feels a bit like overkill because there is no other package manager which currently needs this. Maybe I have missed a better alternative.

@tversteeg
Copy link
Owner

I think a has_required_flag member makes a lot of sense for this situation. Sounds look a good clean solution!

@jayvdb
Copy link
Author

jayvdb commented Aug 15, 2022

It might make more sense to have a hook which is given the entire command line and is able to reject it - then the hook would be usable for other special cases where a declarative approach is a lot of effort

@jayvdb
Copy link
Author

jayvdb commented Aug 17, 2022

Digging a little deeper, I wonder if it would be OK to add a CaptureFlag::Invalidating("--path") to cargo.rs to replace has_invalidating_flag, and CaptureFlag::Required(["-g", "--global"]) to npm.rs which would tell catch that the line should be ignored unless it was found.

Invalidating is easy as it presence in the command args could be handled in handle_capture_flags, which could return a bool to tell capture to ignore the line. Multiple Invalidating would be OR'd.

Required is slightly more involved, as capture would need to see if Required is present in the package managers capture_flags() return value before processing the command args, and verified that it was seen. Required would take a vec of equivalent flags that are OR'd (e.g. "-g" or "--global" are required), and multiple Required would be AND'd.

This approach would mean that flag processing is still declarative, but doesn't involve creating new members like has_required_flag that are unnecessary for most package managers.

@tversteeg
Copy link
Owner

This sounds like a good solution! I think this would make the implementation a lot cleaner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants