-
Notifications
You must be signed in to change notification settings - Fork 61
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
Add AssemblyScript support to compute init and build commands #160
Conversation
e763109
to
2fe6fc8
Compare
pkg/compute/build.go
Outdated
type Toolchain interface { | ||
Name() string | ||
DisplayName() string | ||
StarterKits() []StarterKit | ||
SourceDirectory() string | ||
IncludeFiles() []string | ||
Initialize(out io.Writer) error | ||
Verify(out io.Writer) error | ||
Build(out io.Writer, verbose bool) error | ||
} |
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 don't like the use of interface methods here to model getters for simple values. Would this be better modelled as a Language
struct with an embedded Toolchain
interface? Such as:
type Toolchain interface { | |
Name() string | |
DisplayName() string | |
StarterKits() []StarterKit | |
SourceDirectory() string | |
IncludeFiles() []string | |
Initialize(out io.Writer) error | |
Verify(out io.Writer) error | |
Build(out io.Writer, verbose bool) error | |
} | |
type Toolchain interface { | |
Initialize(out io.Writer) error | |
Verify(out io.Writer) error | |
Build(out io.Writer, verbose bool) error | |
} | |
type Language struct { | |
Name string | |
DisplayName string | |
StarterKits []StarterKit | |
IncludeFiles []string | |
Toolchain | |
} | |
func NewLangauge(name, displayName, string, kits []starterKits, includeFiles []string, toolchain Toolchain) *Language { | |
// ... etc | |
} |
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.
NewLangauge
-> NewLanguage
in your suggestion :)
I personally like the Language struct idea because this NewLanguage
function could be where the "metadata"-y bits that I was talking about could be initialized and verified.
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.
@phamann I like your alternative — structs collect data, and interfaces collect behavior, so your type Language struct seems to best model what's actually going on.
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.
Ok @mccurdyc @peterbourgon Have implemented this in 5d59eb8 let me know your thoughts?
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 like the new abstraction around languages and toolchains 👍
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 - a couple suggestions and I need to refresh, but didn't want to lose my comments.
I'm paranoid :)
pkg/compute/assemblyscript.go
Outdated
// Check if bin directory exists and create if not. | ||
pwd, err := os.Getwd() | ||
if err != nil { | ||
return fmt.Errorf("error getting current working directory: %w", err) | ||
} | ||
binDir := filepath.Join(pwd, "bin") | ||
if err := common.MakeDirectoryIfNotExists(binDir); err != nil { | ||
return fmt.Errorf("error making bin directory: %w", err) | ||
} | ||
|
||
npmdir, err := getNpmBinPath() | ||
if err != nil { | ||
return err | ||
} |
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.
suggestion - thoughts on pulling these "metadata"-y bits into some centralized "initialization" function that gets called once and sets some "metadata" fields on like a config struct or something so that we don't have to have these checks in multiple places.
An additional benefit of this would be that the functions are more focused on what they are supposed to be doing --- e.g., "building" --- and less on validating the environment.
A valid counter argument to this would be then you have dependencies on the metadata fields being set and the functions --- e.g., Build
--- are not entirely self-contained.
pkg/compute/build.go
Outdated
type Toolchain interface { | ||
Name() string | ||
DisplayName() string | ||
StarterKits() []StarterKit | ||
SourceDirectory() string | ||
IncludeFiles() []string | ||
Initialize(out io.Writer) error | ||
Verify(out io.Writer) error | ||
Build(out io.Writer, verbose bool) error | ||
} |
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.
NewLangauge
-> NewLanguage
in your suggestion :)
I personally like the Language struct idea because this NewLanguage
function could be where the "metadata"-y bits that I was talking about could be initialized and verified.
Co-authored-by: Colton J. McCurdy <cmccurdy@fastly.com>
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 like this!
TL;DR
Adds beta AssemblyScript toolchain support to the Compute@Edge commands
fastly compute init
andfastly compute build
. It usesnpm
to validate the package and environment and theasc
toolchain for compilation.What
pkg/compute/init.go
andpkg/compute/build.go
to support multiple languages.pkg/common/exec
.Toolchain
interface to better cater for multiple languages.pkg/compute/rust.go
to support new toolchain interface additions.Toolchain
interface.