Organizing around the project rather than the markdown file

[mcrascal]

I might have the wrong mental model about vs code extensions, but after playing with this, I wonder if this might be a reasonable way forward on a couple items.

I think we should have the extension detect whether or not there is an Evidence project in the current VS code workspace, and use that information to determine which status bar items, or command palette items are available.

If it's possible to use that same approach to decide how to treat .md files, I also think that would be a sensible way to go.

Detecting an Evidence project

• For the foreseeable future, any package.json which includes an "@evidence-dev/evidence" dependency could be safely assumed to be in the root of an evidence project
• Monorepos
• Users co-locate their evidence projects in monorepos. It won't be safe to assume that the above package.json will be in the root of workspace.
• If we find the project root in another directory, all of the status bar / command palette commands should be run with their working directory set to the root of the evidence project, whether it's the root of the workspace or not.

Treatment of status bar items / commands

When an evidence project is detected in the workspace, we should offer all of the commands and status bar items, regardless of what files are open in vscode.

Eventually we might have some commands which are file specific, but right now all of them are project-level.

Treatment of markdown files

It seems like we're facing some weird trade-offs to have the extension whether or not we can safely override the built in markdown features

The options so far are:

• Create a new file extension, e.g .emd
• Add some flags to frontmatter
• Write some sort of detection logic to parse markdown and judge
• ?

If it's possible to use logic beyond just the file extension to determine how to treat the file, I think we could use the above approach to make a simpler judgements about how to treat the .md files that the extension encounters:

1. All .md files inside project-root/pages can safely be treated as evidence markdown
2. All .md files outside of project-root/pages should be treated as regular markdown

For example, the readme.md in the root of an evidence project should not be treated like evidence markdown.

[RandomFractals]

We already perform many Evidence project detection checks and commands enablement.

This was added in (#18)

Current limitation

Mostly due to Sprint 1 only one week of dev constraint to get basic interactive commands working first:

• v1.0.0 only supports Evidence projects at the root/open workspace folder. I mentioned this in slack last week.

We'd need to extend those checks to detect nested Evidence projects for dbt, etc.

[RandomFractals]

Treatment of status bar items / commands

When an evidence project is detected in the workspace, we should offer all of the commands and status bar items, regardless of what files are open in vscode.

Eventually we might have some commands which are file specific, but right now all of them are project-level.

Enabling and activating vscode extensions on startup is taxing and frowned upon in vscode dev community.

Evidence extension and commands get activated on these main language events in VS Code currently:

  "activationEvents": [
    "onLanguage:emd",
    "onLanguage:markdown",
    "onLanguage:javascript",
    "onLanguage:json",
    "onLanguage:svelte",
...

Opening any of those files in VS Code will activate Evidence extension and reveal available commands.

Also, many extensions contribute to the VS Code status bar. So, us taking space there without any emd documents to preview or update is hard to justify.

[RandomFractals]

If it's possible to use logic beyond just the file extension to determine how to treat the file, I think we could use the above approach to make a simpler judgements about how to treat the .md files that the extension encounters:

1. All .md files inside project-root/pages can safely be treated as evidence markdown
2. All .md files outside of project-root/pages should be treated as regular markdown

I like this suggestion and will use it when I add the rest as described in #9 for the markdown detection.

[mcrascal]

1. Makes sense to defer the monorepo support.
2. Can you activate upon detecting a qualifying package.json in the workspace? I agree that always having the 'evidence run' command present in the status bar would not be desirable, but always having it there while you're in an Evidence project seems like the correct behaviour. Fine to defer it to feedback though.
3. Re: Review current emd language configuration and determine why it overwrites built-in .md Open Preview command in vscode #9, that's fantastic!

[RandomFractals]

I actually tried to get workspaceContains to work in activation, but ran into issues. Will revisit it again this week to fine tune that part.

https://code.visualstudio.com/api/references/activation-events#workspaceContains

[RandomFractals]

Most of the listed loose ends in this ticket were already resolved. See other referenced tickets.

The rest will be handled in #64 and other markdown related tickets.