Skip to content
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.

Sign up for GitHub

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

Jump to bottom

chore: consolidate dev and publish implementations #396

Closed
threepointone opened this issue Feb 6, 2022 · 1 comment
Closed

chore: consolidate dev and publish implementations #396

threepointone opened this issue Feb 6, 2022 · 1 comment
Assignees
@threepointone
Labels
maintenance Maintenance task

Comments

@threepointone
Copy link
Contributor

threepointone commented Feb 6, 2022 •
edited
Loading

dev and publish have a bunch of code that should ostensibly be abstracted into common helpers, including but not limited to the esbuild configuration, the worker upload, custom builds, validation, etc. Keeping them separate was useful to figure out what the nuance and differences between them where, until now. But it's starting to get a bit hairy, and can lead to bugs like #288.
@threepointone threepointone self-assigned this Feb 6, 2022
@Electroid Electroid added the maintenance Maintenance task label Feb 6, 2022
@threepointone threepointone mentioned this issue Feb 8, 2022
Closed
@Electroid Electroid mentioned this issue Feb 9, 2022
Closed
petebacondarwin added a commit that referenced this issue Feb 10, 2022
@petebacondarwin
refactor: share worker bundling between both publish and dev comm…
877171c 
…ands

This changes moves the code that does the esbuild bundling into a shared file
and updates the `publish` and `dev` to use it, rather than duplicating the
behaviour.

See #396
Resolves #401
@petebacondarwin petebacondarwin mentioned this issue Feb 10, 2022
Merged
petebacondarwin added a commit that referenced this issue Feb 11, 2022
@petebacondarwin
refactor: share worker bundling between both publish and dev comm…
d5890e2 
…ands

This changes moves the code that does the esbuild bundling into a shared file
and updates the `publish` and `dev` to use it, rather than duplicating the
behaviour.

See #396
Resolves #401
petebacondarwin added a commit that referenced this issue Feb 11, 2022
@petebacondarwin
refactor: share worker bundling between both publish and dev comm…
2bb8d21 
…ands

This changes moves the code that does the esbuild bundling into a shared file
and updates the `publish` and `dev` to use it, rather than duplicating the
behaviour.

See #396
Resolves #401
petebacondarwin added a commit that referenced this issue Feb 12, 2022
@petebacondarwin
refactor: share worker bundling between both publish and dev comm…
bce731a 
…ands

This changes moves the code that does the esbuild bundling into a shared file
and updates the `publish` and `dev` to use it, rather than duplicating the
behaviour.

See #396
Resolves #401
@github-actions github-actions bot mentioned this issue Feb 12, 2022
Merged
@threepointone
Copy link
Contributor Author

This is in a much better place now, closing

mrbbot added a commit that referenced this issue Oct 31, 2023
@mrbbot
Return runtime entry URL from Miniflare#ready (#396)
c22520e 
* Resolve `Miniflare#ready` with runtime entry URL

* Remove `startServer()`

This was a breaking change anyway, as we no longer return an
`http.Server`. Given it's just an alias for `ready`, and doesn't
actually start a server, it doesn't make much sense to keep it.

* Use service name not binding name as service binding designator

This was a mistake and prevented service bindings being bound with
different names to the corresponding bound workers.
mrbbot added a commit that referenced this issue Nov 1, 2023
@mrbbot
Return runtime entry URL from Miniflare#ready (#396)
e7234fe 
* Resolve `Miniflare#ready` with runtime entry URL

* Remove `startServer()`

This was a breaking change anyway, as we no longer return an
`http.Server`. Given it's just an alias for `ready`, and doesn't
actually start a server, it doesn't make much sense to keep it.

* Use service name not binding name as service binding designator

This was a mistake and prevented service bindings being bound with
different names to the corresponding bound workers.
mrbbot added a commit that referenced this issue Nov 1, 2023
@mrbbot
Return runtime entry URL from Miniflare#ready (#396)
95e27ce 
* Resolve `Miniflare#ready` with runtime entry URL

* Remove `startServer()`

This was a breaking change anyway, as we no longer return an
`http.Server`. Given it's just an alias for `ready`, and doesn't
actually start a server, it doesn't make much sense to keep it.

* Use service name not binding name as service binding designator

This was a mistake and prevented service bindings being bound with
different names to the corresponding bound workers.
mrbbot added a commit that referenced this issue Nov 1, 2023
@mrbbot
Return runtime entry URL from Miniflare#ready (#396)
57bef2a 
* Resolve `Miniflare#ready` with runtime entry URL

* Remove `startServer()`

This was a breaking change anyway, as we no longer return an
`http.Server`. Given it's just an alias for `ready`, and doesn't
actually start a server, it doesn't make much sense to keep it.

* Use service name not binding name as service binding designator

This was a mistake and prevented service bindings being bound with
different names to the corresponding bound workers.
This was referenced Feb 10, 2024
Open
Open
Open
Open
Open
Open
This was referenced Feb 17, 2024
Open
Open
Open
Open
Open
Open
Open
@Laurry-gee Laurry-gee mentioned this issue Feb 25, 2024
Open
This was referenced Feb 26, 2024
Open
Open
Open
Open
Open
This was referenced Mar 4, 2024
Open
Open
Open
Open
Open
Open
Open
This was referenced Mar 12, 2024
Open
Open
Open
Open
Open
Open
Open
Open
This was referenced Mar 19, 2024
Open
Open
Open
Open
Open
Open
Open
@Laurry-gee Laurry-gee mentioned this issue Mar 27, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@threepointone threepointone

Labels
maintenance Maintenance task
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@threepointone @Electroid