Auto-Init for VS Code Plugin is too invasive

[gewenyu99]

Originally posted by Matt Johnson-Pint:

I installed the Trunk VS Code Plugin today, which improved my experience working on a docs project that was set up to use Trunk.

However, to my great surprise, I started getting .trunk folders added to any folder I opened with VS Code! This is not surprise in a good way. Many of my projects are already configured with different linters. I work on open source projects with different opinions than my own, etc. It's wild for an extension to behave in this manner.

After some digging, I found the trunk.autoInit setting that controls this, and turned it off. It's fine that this setting exists, but IMHO - it should be false by default. Otherwise, how can one be comfortable instructing teammates to install the extension? Or putting it in a project's .vscode/extensions.json file? It's just too much surprise. Turn it off please.

[gewenyu99]

After talking with the team, here's where we stand:

• This is an attempt to make Trunk Check just work magically everywhere.
• It's by default in single player mode, and not tracked by git so you won't accidentally commit Trunk config in random places.
• It can be disabled in VSCode config.

Would love your opinions on whether this is still overly invasive in your minds, let us know, we'd be happy to discuss.

[mattjohnsonpint]

Hi. Just seeing this here now, since it was migrated.

To answer your question - yes, IMHO this is still overly invasive. While you might like Trunk Check to just work magically everywhere, I, as a user of Trunk, do not. I want Trunk Check to work on projects that have been enabled with Trunk, and I want it to do nothing for projects that have not been enabled. In other words, the preferred model from a user's point of view is opt-in, not opt-out.

Consider that there are thousands of extensions in the VS Code marketplace. I might have any number or combination of them installed on my computer, for whatever projects I'm working on. If I had to opt-out of each of them except for the projects where applicable, that would be very difficult to manage. Instead, I expect each extension to behave itself. A Trunk extension should only take action on Trunk-enabled projects, in the same way that a JavaScript extension should only take action on a JavaScript project. It would be problematic if I opened a Go project and some JavaScript extension started creating or modifying files in my project - whether they are gitignored or not.

Yes, there are some extensions that are always enabled, such as GitHub, Copilot, AWS, etc. But none of these directly modify the files in a project's directory just by being enabled.

An acceptable behavior would be for the extension to look for the presence of a .trunk folder. If it exists, then the extension can take action as appropriate. If it doesn't exist, it should disable itself so that it doesn't interfere with the project. It can continue to watch for a .trunk folder being created, so that if I later call trunk init from a terminal window, then the extension can automagically come to life. There could also be a task from the VS Code command pallet to initialize a project for Trunk, etc.

[ryanfoxtyler]

@gewenyu99 any plans to address this? we're unable to leverage Trunk in our public repos with the current behavior