We don't add frameworks, stacks, libraries or toolkits as their own languages. This project identifies itself as a "Fullstack TypeScript toolkit that enhances Prisma ORM with flexible Authorization layer for RBAC/ABAC/PBAC/ReBAC, offering auto-generated type-safe APIs and frontend hooks." which appears to be entirely Typescript.

React isn't its own language in Linguistic for this same reason. Closing.

@lildude
Thanks for the explanation. I see the point, but I'd like to make some clarifications.

1. ZenStack is indeed a TypeScript toolkit, but the language I'd like to add is the ZModel language it uses. ZModel is a domain-specific language (DSL) for defining data models and access policies, which is actually language-agnostic.
   ZModel Language
   

2. ZModel is a superset of the Prisma Schema Language (.prisma). Given that Prisma schema is already included in Linguistic, I believe ZModel should also qualify for inclusion.

3. We once positioned ZenStack to be a "DSL for defining data and access rules closer to the database". You can see our Hacker News launch long time ago:
   https://news.ycombinator.com/item?id=37750972
   We don’t mind changing our GitHub description to so if it would make some difference.

4. To be able to get the syntax highlight is actually repuested by some ZenStack’s users. Below is the issue created by one of them:
   Provide grammar to Linguist project #823

Since there are already hundreds of users using it, I definitely hope they could get a better DX on GitHub. If you still hold the opinion, may I know what’s the prerequisites it must meet to be qualified for ZModel to get in?

Thanks for the explanation. I’ve reopened it but you need to rename the language to Zmodel as that is what you are adding. Popularity isn’t sufficient for merging now anyway.

Thanks for the explanation. I’ve reopened it but you need to rename the language to Zmodel as that is what you are adding. Popularity isn’t sufficient for merging now anyway.

Hey @lildude , may I know what the up-to-date polarity assessment criteria is?

According to the assessment mentioned in #5756

• At least 2000 files per extension were indexed in the last year (the number you see at the top of the search results) unless the extension is expected to occur only once per repo, then 200 files.
• with a reasonable distribution across unique :user/:repo combinations assessed by manually and randomly clicking through the results.

For Zmodel, the extension is expected to occur only once per repo. Using the search offered in the template, the result is 387 which is more than 200.
https://github.com/search?type=code&q=NOT+is%3Afork+path%3A*.zmodel+model

So, I believe the first rule has been met. Could the issue be with the second rule? If so, is there a specific way I can verify this myself?

For Zmodel, the extension is expected to occur only once per repo. Using the search offered in the template, the result is 387 which is more than 200.

🤔 that doesn't appear to be the case from a quick look through the search results like this repo, or any of the other results where the .zmodel file returned is not in the root of the repo. Your own project has more than one.

This suggests the files will occur at least once per repo and likely more, hence the first criteria applies.

Of course this all makes sense when you consider Prisma models will be for many DB tables and people prefer to break things up for easier maintenance (and ownership in big monorepos) as is the case I first referenced which is taking full advantage of importing the individual .vmodel files in their schema.vmodel.

So I'd say schema.vmodel is likely to occur only once per repo, but not the extension by the design of the fact the individual files can be imported as needed.

@lildude Thanks for the comments and the detailed explanation. The comments has been resovled.

You're right; it is the same case as Prisma, where typically users have only one schema file as their database model in the repo.

The reason we supported multiple schema files because that was a long-requested feature by the user of Prisma when their schema grows to a certain level for better maintenance (Prisma also added preview support recently after we supported it):

Support for splitting Prisma schema into multiple files #2377

Even if people use multiple schema files, there would be a main entry file that could only occur once per repo. So you can use the below search to see the unique repos that use zmodel:

https://github.com/search?type=code&q=NOT+is%3Afork+path%3A*.zmodel+datasource

@lildude The changes have been made based on your feedback. Is there anything else I need to do?

As I mentioned above, since most repos typically have just one schema file unless they break things up for easier maintenance (same for Prisma), I wonder if it might meet the popularity criteria now. Here is the search for unique repos that use zmodel:

https://github.com/search?type=code&q=NOT+is%3Afork+path%3A*.zmodel+datasource

Hello @lildude , any chance we can get this merged soon? Thank you!

I don't review PRs for popularity requirements etc after the initial review until I'm close to making the next release. The next release will be made sometime next week.

When will the request be merged? Looking forward to Zmodel language integration!

NOTE: +1 comments will be flagged. They add no value and don't influence things at all, especially when the PR isn't ready for merging due to failing tests.

@lildude did this one fall through the cracks?

No. There are failing tests. PRs do not get merged until all tests pass. It is the PR author's responsibility to keep an eye on their PRs and resolve failures and conflicts.

When will the request be merged? Looking forward to Zmodel language integration!

Once all tests pass. And even then, the changes in this PR will not appear on GitHub until the next release has been made and deployed. See here for more details.

The next release is scheduled for early June 2025.

No. There are failing tests. PRs do not get merged until all tests pass. It is the PR author's responsibility to keep an eye on their PRs and resolve failures and conflicts.
[...]
The next release is scheduled for early June 2025.

Thankyou! ♥️

You can save time by running rake test locally 😉

@lildude Thanks for the reminder, and sorry for the inconvenience! I had some issues with the Ruby environment on my local machine earlier, but I managed to set up a GitHub codespace and successfully passed the test in the end!

Would you please let me know when you plan to review and merge it if possible? I will keep an eye on it to ensure it doesn’t break again. 😄