feat!: refactor into monorepo with compile and cli packages#192
Merged
Conversation
… config file templates
…e and cli packages
…have direct dependency on antlr types
… fs-extra dependency
…replacement for codeGenerator().generate())
…new parseAndGenerate() function in compile package
…d direct dependency on Model
Merged
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
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.
Fixes #191
This is an initial round of refactoring that converts the existing
sdeverywherepackage into separate@sdeverywhere/compileand@sdeverywhere/clipackages. This sets the stage for adding more packages (build,runtime,check, etc) in the coming days.For this PR, I've kept the implementation as untouched as possible. The changes are limited to:
sdecommand-related files to theclipackagecompilepackageThe only notable exception is that I've removed the
sde generate --genhtmlcommand and supporting web files. There will be a replacement for this implemented using the plugin API; this avoids having it baked into the core, so that we can make it more configurable and have fewer dependencies in core.With these changes in place, we now have a pretty minimal API surface for the
compilepackage. The exact API is subject to change before 1.0, but at least now thecompilepackage is well isolated:For the commit message (and the changelog):
/cc @ToddFincannon