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

Provide a separate warning/setting for modifying files in pub cache from other non-workspace files #2734

Closed
bsutton opened this issue Aug 21, 2020 · 5 comments
Labels
in editor Relates to code editing or language features is enhancement
Milestone

Comments

@bsutton
Copy link

bsutton commented Aug 21, 2020

I regularly work across multiple projects that are inter-related.

Lets say that I have project A and project B.

Project B depends on project A.

The code for both projects are on my local machine.

To create a release of project B I have to change my pubspec to pull Project A from pub.dev (rather than a local path).

This is fine.

The problem is if I forget to move the pubspec dependency for Project A back to a local path.

So the scenario is:

I'm working happily in Project B within vscode.
I control-click through a method that is in Project A.
If find a problem in Project A and start editing the code.

The problem is that the code in Project A is being pulled from .pub-cache.

Whilst dart-code does provide a warning about editing in a external folder I ignore this message because I'm assuming that its just due to the local path to project A.

What I would like to see is that if you open a file in .pub-cache then vscode should make the code non-editable and ideally the notification dialog should be in a more aggressive colour such as red.

@DanTup
Copy link
Member

DanTup commented Aug 24, 2020

Whilst dart-code does provide a warning about editing in a external folder I ignore this message because I'm assuming that its just due to the local path to project A.

This warning shouldn't appear if you open both projects in the same VS Code window (which is the recommended way to work on multiple projects). If you're seeing it there, then we should consider that a bug and fix it. Woking that way, when the warning appears, you know you might be doing something wrong and should stop ignoring it :-)

I don't think there's much more we can do - there was a request for marking files as readonly in VS Code (microsoft/vscode#17670) but it doesn't seem likely to be implemented. I don't want to make the warning red, as it's not really an error and that could also be confusing (I'm also not certain there are no instances where it's valid to do this - I've debugged a few packages by adding prints into their code in pubspec because it was easiest 😄).

@DanTup DanTup added the awaiting info Requires more information from the customer to progress label Aug 24, 2020
@bsutton
Copy link
Author

bsutton commented Aug 25, 2020

Hmm, I take your point. I too have occasionally hacked the cache to due some crude testing.

The problem is that it causes me grief more often than it helps.

The warning is only appearing if I'm opening files from a folder that isn't currently opened.
I just do this quite a lot :)
So I think its currently behaving as designed.

How about a middle ground.
Leave it blue if its just a normal external folder but make it red if its the cache.
I really do think that editing the cache should be considered a more critical mistake than just editing source from another project.

Playing in the cache will result in code being lost whilst edit source in another project will not normally result in lost code.

@DanTup
Copy link
Member

DanTup commented Aug 25, 2020

The warning is only appearing if I'm opening files from a folder that isn't currently opened.
I just do this quite a lot :)

Is there a reason for this? If you're deliberately making changes to the project, it would be much better to add it to your workspace.

I really do think that editing the cache should be considered a more critical mistake than just editing source from another project.

Sure, but the meaning of "error" suggests something failed or went wrong. If I got an error when editing a file, I would expect the editor did not apply or was rolled back. I think it'd be confusing to use here (it may suggest we blocked you from editing the file you shouldn't edit, but we didn't - so you need to be aware you changed it).

I think it would be better to not have the popup when it's not needed than have two levels of severity. Can you describe the setup when you do this a bit more? Maybe we can improve this - for example, if it's a local path dependency, what if the notification had a button "Add to Workspace". That would encourage adding to the workspace when editing, but if you really didn't want to, it would at least give you some indicator of whether it was a pubcache file (eg. the button wouldn't be there?).

@bsutton
Copy link
Author

bsutton commented Aug 25, 2020 via email

@DanTup
Copy link
Member

DanTup commented Aug 26, 2020

Ok, I've split the existing warning into two separate warnings - one for editing in pubcache (this is just a crude check on the path), and one for other files outside your workspace. This means there are now two settings that are set with their "Don't warn me" options:

"dart.warnWhenEditingFilesOutsideWorkspace": true,
"dart.warnWhenEditingFilesInPubCache": true,

These both default to true, but you can set the first one to false and you'll not be warned for files outside the pub cache (but are outside your workspace). This allows you to only see warnings when you're editing in the pubcache, which will hopefully uncondition you from ignoring the warnings :-)

Hope this seems reasonable enough!

@DanTup DanTup changed the title Disallow editing of files in .pub-cache Provide a separate warning/setting for modifying files in pub cache from other non-workspace files Aug 26, 2020
@DanTup DanTup added in editor Relates to code editing or language features is enhancement and removed awaiting info Requires more information from the customer to progress labels Aug 26, 2020
@DanTup DanTup added this to the v3.14.0 milestone Aug 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in editor Relates to code editing or language features is enhancement
Projects
None yet
Development

No branches or pull requests

2 participants