-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: generate stubs for FTL modules #1106
Conversation
83f55fe
to
198e0e2
Compare
gatherShemas(moduleSchemas, modules, modules[dep], out) | ||
if dep != "builtin" { | ||
depModule, ok := e.projects[dep] | ||
// TODO: should we be gathering schemas from dependencies without a project? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Need to ask someone about this
0e2e55b
to
6aa1e3b
Compare
// It is used to: | ||
// - build the dependency graph | ||
// - map changes in the file system to the project | ||
type ProjectKey string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit iffy on how wise it was to do it like this. It extends to a Project's Dependencies []ProjectKey
.
I imagine one day we'd want to make a ModuleConfig.Module
into a ModuleName type?
Projects can only depend on Modules (not ExternalLibraries), but they are all accessed via buildengine's map[ProjectKey]Project
, and declaring all dependencies as ProjectKeys lessens the amount of recasting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Up to you, but having it in Dependencies
definitely doesn't make sense as an external lib can't be a dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weren't you getting rid of ProjectKey?
// It is used to: | ||
// - build the dependency graph | ||
// - map changes in the file system to the project | ||
type ProjectKey string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Up to you, but having it in Dependencies
definitely doesn't make sense as an external lib can't be a dependency.
buildengine/topological.go
Outdated
@@ -8,34 +8,37 @@ import ( | |||
|
|||
// TopologicalSort returns a sequence of groups of modules in topological order | |||
// that may be built in parallel. | |||
func TopologicalSort(graph map[string][]string) [][]string { | |||
modulesByName := map[string]bool{} | |||
func TopologicalSort(graph map[ProjectKey][]ProjectKey) [][]ProjectKey { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to above, ProjectKey
doesn't make semantic sense here, and doesn't ensure enough type safety. I'd probably either back it out or split the types even further:
//sumtype:decl
type ProjectKey interface { projectKey() }
type ModuleKey string
func (ModuleKey) projectKey() {}
type ExternalLibraryKey string
func (ExternalLibraryKey) projectKey() {}
This allows either to be used, or only one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll back out ProjectKey somewhat, i think that's the best thing for now.
I was also thinking along the lines of having separate types, but figured to do a fully thought through ModuleKey/ModuleName type would be a lot farther reaching, and beyond the current scope of what I wanted to change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but please add some tests.
"testing" | ||
|
||
"github.com/alecthomas/assert/v2" | ||
|
||
"github.com/TBD54566975/ftl/common/moduleconfig" | ||
"github.com/TBD54566975/ftl/internal/log" | ||
) | ||
|
||
func TestDiscoverModules(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a test that includes an external library that imports one of the existing ftl modules in testdata.
// It is used to: | ||
// - build the dependency graph | ||
// - map changes in the file system to the project | ||
type ProjectKey string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Weren't you getting rid of ProjectKey?
c7f19e6
to
df13243
Compare
@alecthomas I kept ProjectKey but just for getting projects via the key ( |
# Conflicts: # buildengine/discover_test.go
545c008
to
30108a4
Compare
30108a4
to
372c565
Compare
@@ -0,0 +1,11 @@ | |||
package lib |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice.
ftl build
andftl dev
now accept a list of external library directories which need stubs generated of the ftl modules it useseg:
This example finds all go modules in the
go
folder as well as treatinggo/lib
as an external library