Choose the "main" file defined in package.json as the default startup file

[mousetraps]

Right now we don't have any logic defined to parse the package.json file (other than for npm packages), so we shouldn't do this feature if we don't also enable executing scripts in package.json, and who knows what else, lest it open us up to an inconsistent experience.

I'm not entirely convinced this feature is worth the effort when you consider the slew of issues it opens us up to (what with invalid package.json files, etc.), but maybe I'm wrong.

[MystK]

I think it's okay to parse the main parameter for now because it's a separate thing from the scripts parameter.

I don't think it's an inconsistent experience considering the dependencies, like you said, are already parsed.

I think it would lead to an overall more consistent experience if you take into account that the default startup file currently is defined twice, once in package.json and again through Visual Studio.

It would be great to be able to set the default startup file in Visual Studio and have the package.json main parameter change also.

[mousetraps]

I was referring to an inconsistent experience between not also implementing scripts and config. So implementing this feature basically means we're commited to this entire feature set. Currently things make sense once youunderstand that "oh, the project settings dont mirror package.json. But it gets confusing when only some things are different because we've set the expectation that everything will work this way. So definitly not a blocker, just something to be aware of. I agree that this would be nice to have, and we should just ensure we understand the scope of the feature set before committing to any individual feature.

Parsing is one thing, but currently we don't edit package.json at all yet. We leave that for npm cli to do. Again not a blocker, just something to consider.

[MystK]

Ahh, I understand now. That makes sense. Would the main and scripts parameter be the only issue? I could see in the near future parsing the main parameter by NVST for the default startup file and perhaps Task Runner Explorer could support the scripts?

[mousetraps]

Maybe? We'd need to investigate. Would you be interested in looking into what package.json parameters we might need to support?

Re: task runner explorer... interesting idea, but we should refrain from taking hard dependencies on other extensions if we can help it.

Perhaps a reasonable compromised experience would be to read these values from package.json, but not write to it. Similar to how we read the node.exe path from PATH, and we display this helper text in the node.exe path input box in project properties. If someone wants to modify project properties, they can, and then the project would just use different settings than package.json.

[peterblazejewicz]

I think Azure uses as defaults:

• index.js
• server.js
• app.js

(at least for web app/web job)

The NTVS could use similar defaults, the tools could have experience.
Thanks!

[paulvanbrenk]

We're taking this into account when we'll implement a new project system. Currently the behavior you want is available in the "open folder' scenario.