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

Source map support for injectManifest makes incorrect assumptions #3233

Open
steverep opened this issue Jul 25, 2023 · 5 comments · May be fixed by #3234
Open

Source map support for injectManifest makes incorrect assumptions #3233

steverep opened this issue Jul 25, 2023 · 5 comments · May be fixed by #3234

Comments

@steverep
Copy link

Library Affected:
workbox-build

Browser & Platform:
n/a

Issue or Feature Request Description:
It looks like source map support was added for the Webpack plugin in #2239 when injecting the manifest. However, there is no such support for the injectManifest method in the workbox-build package. It would be helpful if the same code could be applied there, i.e. if a source map exists for swSrc then write an adjusted one for swDest.
@steverep steverep mentioned this issue Jul 26, 2023
Merged
@steverep
Copy link
Author

Looks like support exists but there are bugs in the implementation. I commented on the original PR.

For my case, it is appearing as if there is no support because the original source map is just being overwritten rather than writing a new one with the new filename and updating the URL.

@steverep steverep changed the title No source map support for injectManifest in workbox-build Source map support for injectManifest makes incorrect assumptions Jul 26, 2023
@steverep steverep linked a pull request Jul 28, 2023 that will close this issue
Open
@tomayac
Copy link
Member

tomayac commented Apr 25, 2024

Hi there,

Workbox is moving to a new engineering team within Google. As part of this move, we're declaring a partial bug bankruptcy to allow the new team to start fresh. We realize this isn't optimal, but realistically, this is the only way we see it working. For transparency, here're the criteria we applied:

Thanks, and we hope for your understanding!
The Workbox team

@tomayac tomayac closed this as completed Apr 25, 2024
@steverep
Copy link
Author

@tomayac sorry I don't understand the closing issues move at all. I don't think an "if I don't see it it doesn't exist" strategy works in software development (or anywhere in life for that matter). The code hadn't been touched in almost a year, so why would issues filed within that time be stale or otherwise worthy of closing without actual triage?

This problem exists and there's a PR to fix it, so am I just supposed to open a new one just to be in 2024?

@tomayac
Copy link
Member

tomayac commented Apr 25, 2024

Sorry, looks like this should not have been closed since it has an active PR. Reopening.

@tomayac tomayac reopened this Apr 25, 2024
@steverep
Copy link
Author

steverep commented May 2, 2024

Sorry, looks like this should not have been closed since it has an active PR. Reopening.

Thank you. I updated the PR with the recent changes so the test workflow can be run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(workbox-build): make source map filename consistent with injected source file steverep/workbox
2 participants
@tomayac @steverep