Add support for dynamic import()s on the server-side
#3193
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
9 Ignored Deployments
|
This was referenced Jan 6, 2023
|
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
a661cdd to
468260f
Compare
0dd4f91 to
35aabb8
Compare
468260f to
a4c98cd
Compare
35aabb8 to
5731215
Compare
a4c98cd to
44ca034
Compare
5731215 to
99850bb
Compare
99850bb to
c045d4f
Compare
c045d4f to
52a467e
Compare
|
sokra
requested changes
Jan 11, 2023
Benchmark for d516115
Click to view full benchmark
|
300fa15 to
005f61a
Compare
|
I'm going to merge this directly as our CI is too slow to handle the amount of merges currently happening. |
Benchmark for 9a4dba0Click to view benchmark
|
jridgewell
added a commit
that referenced
this pull request
Jan 12, 2023
The `processed_assets` `IndexSet` was performing deduplication on the `AssetVc`, which is the same between static (`import ... from "foo"`) and dynamic (`import("foo")`) imports of the same specifier. But, the _reference_ to those assets is different, and generates different chunking semantics. In order for both to succeed, we need to process both assets.
Coupled with #3193's ability to load chunks on the server side, this fixes fixes WEB-381.
kodiakhq bot
pushed a commit
that referenced
this pull request
Jan 13, 2023
…3297) The `processed_assets` `IndexSet` was performing deduplication on the `AssetVc`, which is the same between static (`import ... from "foo"`) and dynamic (`import("foo")`) imports of the same specifier. But, the _reference_ to those assets is different, and generates different chunking semantics. In order for both to succeed, we need to process both assets. Coupled with #3193's ability to load chunks on the server side, this fixes fixes WEB-381.
jridgewell
pushed a commit
to vercel/next.js
that referenced
this pull request
Mar 10, 2023
…epo#3193) This PR separates Turbopack's `runtime.js` into two: - the Browser/DOM implementation, which uses `<script>` and `<link>` tags for dynamically loading chunks; - the Node.js/CommonJS implementation, which uses `require` instead. ~~The two runtimes share a lot of code, but I'm not sure what's the best approach for sharing this logic, or even if we should, so for now they are two separate entities.~~ The shared code between the two runtimes is now in a separate file to avoid duplication. Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
jridgewell
added a commit
to vercel/next.js
that referenced
this pull request
Mar 10, 2023
…ercel/turborepo#3297) The `processed_assets` `IndexSet` was performing deduplication on the `AssetVc`, which is the same between static (`import ... from "foo"`) and dynamic (`import("foo")`) imports of the same specifier. But, the _reference_ to those assets is different, and generates different chunking semantics. In order for both to succeed, we need to process both assets. Coupled with vercel/turborepo#3193's ability to load chunks on the server side, this fixes fixes WEB-381.
sokra
pushed a commit
to vercel/next.js
that referenced
this pull request
Mar 13, 2023
…epo#3193) This PR separates Turbopack's `runtime.js` into two: - the Browser/DOM implementation, which uses `<script>` and `<link>` tags for dynamically loading chunks; - the Node.js/CommonJS implementation, which uses `require` instead. ~~The two runtimes share a lot of code, but I'm not sure what's the best approach for sharing this logic, or even if we should, so for now they are two separate entities.~~ The shared code between the two runtimes is now in a separate file to avoid duplication. Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
sokra
pushed a commit
to vercel/next.js
that referenced
this pull request
Mar 13, 2023
…ercel/turborepo#3297) The `processed_assets` `IndexSet` was performing deduplication on the `AssetVc`, which is the same between static (`import ... from "foo"`) and dynamic (`import("foo")`) imports of the same specifier. But, the _reference_ to those assets is different, and generates different chunking semantics. In order for both to succeed, we need to process both assets. Coupled with vercel/turborepo#3193's ability to load chunks on the server side, this fixes fixes WEB-381.
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Jul 25, 2024
…epo#3193) This PR separates Turbopack's `runtime.js` into two: - the Browser/DOM implementation, which uses `<script>` and `<link>` tags for dynamically loading chunks; - the Node.js/CommonJS implementation, which uses `require` instead. ~~The two runtimes share a lot of code, but I'm not sure what's the best approach for sharing this logic, or even if we should, so for now they are two separate entities.~~ The shared code between the two runtimes is now in a separate file to avoid duplication. Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Jul 29, 2024
…epo#3193) This PR separates Turbopack's `runtime.js` into two: - the Browser/DOM implementation, which uses `<script>` and `<link>` tags for dynamically loading chunks; - the Node.js/CommonJS implementation, which uses `require` instead. ~~The two runtimes share a lot of code, but I'm not sure what's the best approach for sharing this logic, or even if we should, so for now they are two separate entities.~~ The shared code between the two runtimes is now in a separate file to avoid duplication. Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
ForsakenHarmony
pushed a commit
to vercel/next.js
that referenced
this pull request
Aug 1, 2024
…epo#3193) This PR separates Turbopack's `runtime.js` into two: - the Browser/DOM implementation, which uses `<script>` and `<link>` tags for dynamically loading chunks; - the Node.js/CommonJS implementation, which uses `require` instead. ~~The two runtimes share a lot of code, but I'm not sure what's the best approach for sharing this logic, or even if we should, so for now they are two separate entities.~~ The shared code between the two runtimes is now in a separate file to avoid duplication. Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR separates Turbopack's
runtime.jsinto two:<script>and<link>tags for dynamically loading chunks;requireinstead.The two runtimes share a lot of code, but I'm not sure what's the best approach for sharing this logic, or even if we should, so for now they are two separate entities.The shared code between the two runtimes is now in a separate file to avoid duplication.