Commit Graph

4 Commits

Author SHA1 Message Date
Sebastian Markbåge
3f73dcee37 Support named exports from client references (#20312)
* Rename "name"->"filepath" field on Webpack module references

This field name will get confused with the imported name or the module id.

* Switch back to transformSource instead of getSource

getSource would be more efficient in the cases where we don't need to read
the original file but we'll need to most of the time.

Even then, we can't return a JS file if we're trying to support non-JS
loader because it'll end up being transformed.

Similarly, we'll need to parse the file and we can't parse it before it's
transformed. So we need to chain with other loaders that know how.

* Add acorn dependency

This should be the version used by Webpack since we have a dependency on
Webpack anyway.

* Parse exported names of ESM modules

We need to statically resolve the names that a client component will
export so that we can export a module reference for each of the names.

For export * from, this gets tricky because we need to also load the
source of the next file to parse that. We don't know exactly how the
client is built so we guess it's somewhat default.

* Handle imported names one level deep in CommonJS using a Proxy

We use a proxy to see what property the server access and that will tell
us which property we'll want to import on the client.

* Add export name to module reference and Webpack map

To support named exports each name needs to be encoded as a separate
reference. It's possible with module splitting that different exports end
up in different chunks.

It's also possible that the export is renamed as part of minification.
So the map also includes a map from the original to the bundled name.

* Special case plain CJS requires and conditional imports using __esModule

This models if the server tries to import .default or a plain require.
We should replicate the same thing on the client when we load that
module reference.

* Dedupe acorn-related deps

Co-authored-by: Mateusz Burzyński <mateuszburzynski@gmail.com>
2020-11-30 14:37:27 -08:00
Sebastian Markbåge
e41fd1fc06 Support ESM module loaders in Flight fixture (#20229)
This lets the Flight fixture run as "type": "module" or "commonjs".

Experimental loaders can be used similar to require.extensions to do the
transpilation and replacement of .client.js references.
2020-11-12 08:11:05 -08:00
Sebastian Markbåge
e855f91e85 [Flight] Expand the fixture to use require.extensions (#20209)
* Expand fixture

Use .server convention. /server/index.js should really change too so it can be compiled but for now we treat it as bootstrapping code outside the compiled code.

Move App.server. It's part of the application code rather than the infra.

Add hybrid component used in both server/client and an extra component shared by multiple entry points.

* Use require.extensions to replace .client imports

The simplest server doesn't need AOT compilation. Instead we can just
configure require.extensions. This is probably not the best idea to use
in prod but is enough to show the set up.
2020-11-10 12:48:51 -08:00
Dan Abramov
2af07d3f4d [Flight Fixture] Server + Client Components (#20150) 2020-11-03 03:00:23 +00:00