Feat add deno support - Githubissues

CommunityToolkit / Aspire

A community project with additional components and extensions for .NET Aspire

MIT License

227 stars 29 forks source link

Feat add deno support #137

Closed brian-guerrero closed 1 month ago

brian-guerrero commented 1 month ago

Closes #109

PR Checklist

[x] Created a feature/dev branch in your fork (vs. submitting directly from a commit on main)
[x] Based off latest main branch of toolkit
[x] PR doesn't include merge commits (always rebase on top of our main, if needed)
[x] New integration
- [x] Docs are written
- [x] Added description of major feature to project description for NuGet package (4000 total character limit, so don't push entire description over that)
[x] Tests for the changes have been added (for bug fixes / features) (if applicable)
[x] Contains NO breaking changes
[x] Every new API (including internal ones) has full XML docs
[x] Code follows all style conventions

Other information

brian-guerrero commented 1 month ago

@dotnet-policy-service agree

aaronpowell commented 1 month ago

Would it make more sense to have this ship as a standalone integration rather than part of the Node.js extensions pack?

I'm thinking of the discoverability of integration, I'd be looking for a Hosting.Deno package (and this is the thing behind Bun too).

Also, it'd reduce the confusion when the builder API returns a DenoResource not NodeResource.

brian-guerrero commented 1 month ago

That makes sense. I'm thinking for DenoAppResource extensions we can have a an AddDenoApp, AddDenoTask (this would be equivalent to AddNpmApp), and AddViteApp (to have parity with NodeAppResource).

aaronpowell commented 1 month ago

Having a standalone integration means that we don't have to try to make Deno "conform" to any of the Node designs/naming and instead it can leverage terminology that makes sense for Deno devs.

brian-guerrero commented 1 month ago

Ended up staying away from an AddViteApp extension to keep the use cases pretty vanilla for Deno. One of my two Deno example projects is a Vite + Deno + TS so that should help anyone interested in that approach.

Alirexaa commented 1 month ago

@aaronpowell, We should squash feature branches instead of merge commit. This approach keeps the main branch history cleaner.

aaronpowell commented 4 weeks ago

@aaronpowell, We should squash feature branches instead of merge commit. This approach keeps the main branch history cleaner.

I kind of like having the full history as it makes it easier to do historical tracing of why something was done the way it was, rather than it being in a single commit that you then have to go and find the PR for and dig through there.

But when it's a large PR (like this or the Aspire 9 one) it probably makes more sense.