Tooling package: intended for use in VS Code, CLI... - #256
Draft
freekh wants to merge 1780 commits into
Draft
Conversation
Version Packages
Users must now add modules that are editable to this file. This is the disadvantage. The advantage is that Val no longer needs to evaluate files using QuickJS. So no need for QuickJS, no need for heavy caching in the content server, nor will the proxy need to load files from github (before patching). Now the proxy simply reads the val.modules files instead of loading this from github. Overall there's less magic. Everything will load much faster both in dev and prod. We also believe this is a concept that should be relatively familiar to many people, in particular those used to sanity. The val.modules files can be extended also be used to hide or give permissions on modules or how files are shown in the UI... The plan is to test this out first before changing too much making it harder to revert (yes: we could git revert but that might not be easy once we start piling on things). That means we will keep QuickJS and the Service class that can evaluate files for now. There's a lot of questions around whether this is a good idea. Will it even work in proxy / prod mode? Can we get hot module replacement working when Val is enabled? Did it work before? What do we do now with the VS code extension - will it use quickjs or will it use something else? Finally, although we believe this makes Val less magical, it is another thing to remember - to add a editable module you must declare it val.modules - it will be something easy to forget. Some tooling is expected to be necessary to make up for it that, but are will this tooling hurt devex, will they be expensive to make?
Still needs to be updated... Hoping that will happen at some point :)
Introducing the val.modules file
Version Packages
Need a simpler way to do most server operations. Believe ValOps might be the right abstraction
Module Ids looked like this: /test/foo Module file path looks like this: /test/foo.val.ts Why? We need to know the complete path of the source file to be able to create changes to it. Since the module file path includes "." we had to have another separator: ?p=. So source paths goes from looking like this: /test."foo" to /test.val.ts?p="foo"
We changed the format of patches and we believe we won't have the same view anymore so hopefully we will remember to remove the whoel thing
Currently it seems to be working but no validation is done. Also no errors are handled. The plan is to continue on this path and once ValOpsHttp is working and we can add changes in production, we'll circle back and take care of this. The reason: it is urgent to get changes in prod up and running (blank needs this)
... Other major changes: files are loaded using patch id, which is shimmed in when files are coming from patches, sha256 can now be removed but because of richtext we're waiting with that.
Version Packages
Version Packages
Async prettier doesn't work in jest v29. It will supposedly be fixed in v30, which is currently in alpha.
Bump prettier version in root to latest
…ing-patches-in-studio Feat/add error handling to failing patches in studio
…lso return errors
…esignatures on the assert methods
... We plan on using this do runtime type verification. NOTE: we should use assert always in the validation methods. Right now we are not doing that. NOTE: we did think about whether it made sense for it to recurse or not. In the end it does not (expect where it makes sense :})
Implement schema assert
Both the VS Code extension, CLI and possibly the server (through the UI), needs to to generate and apply fixes to validation errors. It feels like there might be other things as well which all tooling requires. This package unifies that.
|
freekh
marked this pull request as draft
September 9, 2024 15:02
freekh
force-pushed
the
main
branch
2 times, most recently
from
March 1, 2025 18:19
db2e3c3 to
75cdcf9
Compare
freekh
force-pushed
the
main
branch
3 times, most recently
from
September 30, 2025 14:34
df12780 to
3004c84
Compare
freekh
force-pushed
the
main
branch
2 times, most recently
from
January 21, 2026 05:09
272f3ac to
8d6daf7
Compare
freekh
force-pushed
the
main
branch
2 times, most recently
from
May 19, 2026 19:39
a72dec0 to
9a45969
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The VS Code extension, CLI and possibly @valbuild/server (through the UI), needs to be able to generate and apply fixes to validation errors. It feels like there might be other things as well which all different tools requires, so we create a package and move all common functionality from VS Code extension and CLI to this package.
Our first goal is to generate fixes in VS Code, CLI and beyond with the same code.