[Feature Request] Multiple entry zmodels in VS Code extension

[platon-ivanov]

Is your feature request related to a problem? Please describe.
Currently using a structure with multiple entry zmodel schemas in different directories with their own User models or models with @@auth flags only respects one of the auth models in the VS Code extension.

- dbs
  - db1
    - schema.zmodel
  - db2
    - schema.zmodel

model User {
  @@allow('read', auth() == this) // works fine in `db1` directory. "incompatible operand types" when in `db2` directory.
}

Describe the solution you'd like
As @jiashengguo pointed out, a configuration setting could be introduced to support multiple schemas:

I think it's related to how the VSCode plugin works. From VSCode point of view, there is no entry schema as in CLI, so it just loads all the ZModel file could find in the project and try to compile them together. That's why you will see the error because there are two User models now.

I think in order to support multiple schema set in the same project, we probably need to introduce some configuration setting like

{
  "zmodelEntries": ["**/dbs/db1/schema.zmodel",  "**/dbs/db2/schema.zmodel"]  
} 

[jasonmacdonald]

I just hit this as well and couldn't figure out why my schemas were now throwing errors. We use a mono repo, and I added another schema to a package we are building for a Zenstack plugin as an artifact for testing.

Thanks for finding this. It was causing me some undue stress trying to determine why I was getting this error. At least now I know why and that it's just VSCode, but it would be good to resolve this issue as, like me, others may hit this error and not realize the root cause.

[jasonmacdonald]

@ymc9 I might look into this, as it's becoming more of a nuisance. Do you have any suggestions or preferences for correcting this before I start? I'd prefer not to go down the wrong path at the start.

[ymc9]

Hi @jasonmacdonald , thanks for offering to fix it! Since it's only for IDE we probably should configure it inside vscode settings. Let me check that part of code and share more thoughts back here soon.

[ymc9]

Hey @jasonmacdonald , thanks for the wait. I checked the code and here're my thoughts:

• First we can introduce a VSCode extension setting to specify the "entry point" zmodel patterns. Maybe just use glob patterns? Right now the only format ZenStack has is the one about formatting. You can use this code as a reference: https://github.com/zenstackhq/zenstack/blob/df9b0ff504feeb1db071bd1dee9f95d1e2acc619/packages/schema/src/language-server/zmodel-formatter.ts#L81C1-L82C1

• Then the next thing is to use the settings to control what files are indexed by the language server. I believe this can be achieved by overriding the base includeEntry method in the ZModelWorkspaceManager. There we can match the entry uri against the glob patterns to make a verdict.

Btw, the language server code is bundled during build, which can make debugging a big hard. I've made a draft PR here to show how you can turn off the bundling and directly use normal build output. With this you should be able to use the VSCode launch configurations to start the extension host and attach to the language server.

#1811

Please let me know if you run into any hurdle!

[jasonmacdonald]

Hey @jasonmacdonald , thanks for the wait. I checked the code and here're my thoughts:

• First we can introduce a VSCode extension setting to specify the "entry point" zmodel patterns. Maybe just use glob patterns? Right now the only format ZenStack has is the one about formatting. You can use this code as a reference: https://github.com/zenstackhq/zenstack/blob/df9b0ff504feeb1db071bd1dee9f95d1e2acc619/packages/schema/src/language-server/zmodel-formatter.ts#L81C1-L82C1
• Then the next thing is to use the settings to control what files are indexed by the language server. I believe this can be achieved by overriding the base includeEntry method in the ZModelWorkspaceManager. There we can match the entry uri against the glob patterns to make a verdict.

Btw, the language server code is bundled during build, which can make debugging a big hard. I've made a draft PR here to show how you can turn off the bundling and directly use normal build output. With this you should be able to use the VSCode launch configurations to start the extension host and attach to the language server.

#1811

Please let me know if you run into any hurdle!

This is still on my list, but I needed to switch focus last week due to unforeseen circumstances. I hope to get back to looking at this soon.

[ymc9]

Hey @jasonmacdonald , thanks for the wait. I checked the code and here're my thoughts:

• First we can introduce a VSCode extension setting to specify the "entry point" zmodel patterns. Maybe just use glob patterns? Right now the only format ZenStack has is the one about formatting. You can use this code as a reference: https://github.com/zenstackhq/zenstack/blob/df9b0ff504feeb1db071bd1dee9f95d1e2acc619/packages/schema/src/language-server/zmodel-formatter.ts#L81C1-L82C1
• Then the next thing is to use the settings to control what files are indexed by the language server. I believe this can be achieved by overriding the base includeEntry method in the ZModelWorkspaceManager. There we can match the entry uri against the glob patterns to make a verdict.

Btw, the language server code is bundled during build, which can make debugging a big hard. I've made a draft PR here to show how you can turn off the bundling and directly use normal build output. With this you should be able to use the VSCode launch configurations to start the extension host and attach to the language server.
#1811
Please let me know if you run into any hurdle!

This is still on my list, but I needed to switch focus last week due to unforeseen circumstances. I hope to get back to looking at this soon.

Sure. Please take your time! I'm wrapping up v2.8 release but we can always release a patch whenever you have time to work on the PR.