https://github.com/tylim88/firelaw

🔥Write truly safe and scalable Firestore Rules, Transpile Typescript to Security Rules!
https://github.com/tylim88/firelaw

firebase firestore firestore-rules scalable transpiler typescript

Last synced: about 2 months ago
JSON representation

🔥Write truly safe and scalable Firestore Rules, Transpile Typescript to Security Rules!

• Host: GitHub
• URL: https://github.com/tylim88/firelaw
• Owner: tylim88
• License: mit
• Created: 2021-11-10T03:39:33.000Z (over 4 years ago)
• Default Branch: main
• Last Pushed: 2023-06-22T16:37:31.000Z (about 3 years ago)
• Last Synced: 2025-03-27T02:38:50.528Z (over 1 year ago)
• Topics: firebase, firestore, firestore-rules, scalable, transpiler, typescript
• Language: TypeScript
• Homepage:
• Size: 1.57 MB
• Stars: 2
• Watchers: 2
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • Changelog: CHANGELOG.md
  • License: LICENSE

Awesome Lists containing this project

README

          




		

		
Firelaw 烈火戒





		

				

			

			 

			

				

			

			 

			

				

			

			 

			

			 

			

				

			

			 

			

				

			

			 

			

				

			

			 

			

				

			

			 

			

				

			

			 

			

				

			



I decided to stop working on this project after I found out that the security rule methods does not support nested object well enough, the language has too much limitation.

Hence it is pointless to continue this project, there is no enough value.

You should be ok with read operations, because read rule is quite simple, but this is not the case with write operations.

My advice is to validate your data in cloud function instead, and use good libraries like yup, joi and zod.

You lose optimistic update in front end, but I think that is acceptable.

If you don't want keep the optimistic update, use trigger instead.

TLDR, Firestore security rule suck, don't use it with nested object.

## Update

I will repurpose this library into VS Code extension that lint types of Firestore Security Rules based on Firelord type