-
Notifications
You must be signed in to change notification settings - Fork 1.8k
draft: merge webpack to vite #2371
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.
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
Conversation
|
@@ -26,24 +26,28 @@ import './css/doc-explorer.css'; | |||
import './css/history.css'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how this file ended up in src
(maybe I moved it?) but it should not be part of the resulting build. It's meant to just be an example implementation. It should be example.js
, and not be a typescript file. The bundler should not pick up this file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it seems that I didn't notice that tsc will compile all the files in the directory, and src/main.tsx is only used as the entry script of the web application (the official practice of the vite project). Probably should be excluded from tsc or moved to resources/ directory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, yes src/main.tsx
should be src/example.js
and should not be used as the bundling entry point, that should be src/cdn.js
if you see in the webpack config. I originally had this file in the resources/
directory, it must have been moved during the tabs effort. src/index.js
is the ESM main, which is different, and not what you want to treat as the entrypoint with vite.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed, I excluded src/main.tsx
from tsconfig.json/tsconfig.esm.json
1a0a3ef
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this file should not be importing individual css files either, the idea is that it's supposed to show a demo using the CDN bundle and thus the css bundle... I need to clean this file up in another PR!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
huh weird, webpack supports it for umd
by just un-splitting the code and inlining the dynamic imports. this is going to be a big problem then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the esm bundle users want dynamic imports for SSR, and the cdn users just want a single file and don't really need dynamic imports. there has to be a way? we originally were using inline require()
statements when I inherited the project, as dynamic import was only a proposal then, but now esbuild
can't handle that, so we switched to modern dynamic imports for codemirror/etc, which requires window
to be present on import (thus why we can't import top-level)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rxliuli it seems some of these solutions might work:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I played around with this too recently. There's a option that inlines all dynamic imports:
export default defineConfig({
// ...
build: {
lib: { /* libarary mode */ },
rollupOptions: {
external: ['react', 'react-dom'],
output: { inlineDynamicImports: true },
},
},
});
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
brilliant!
Codecov Report
@@ Coverage Diff @@
## main #2371 +/- ##
==========================================
- Coverage 65.70% 64.72% -0.99%
==========================================
Files 85 81 -4
Lines 5106 5321 +215
Branches 1631 1703 +72
==========================================
+ Hits 3355 3444 +89
- Misses 1747 1873 +126
Partials 4 4
Continue to review full report at Codecov.
|
* - webpack dev server | ||
*/ | ||
|
||
import React from 'react'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this file should not contain imports. this example was meant to be a CDN usage example, that tests the CDN example using the UMD without esm or any bundling. this example implementaiton is not a file for users to import, I hope that's clear. the vast amount of our users use the unpkg/jsdelivr bundle, not the esm import and a bundler. please see the comment at the top of this file
|
||
export default defineConfig({ | ||
plugins: [ | ||
// reactRefresh(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's an explanation of how library mode works:
https://vitejs.dev/guide/build.html#library-mode
we need to use this, and specify react
and react-dom
as externals, so the shipped UMD bundle has parity and doesn't break existing implementations.
we need the demo script for development to use this UMD global, and not use imports
, because the former is more widely used
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it will help you a lot to just take some time to study the webpack configuration, and understand how users are consuming this bundle, and try to re-create the same with vite
@@ -0,0 +1,188 @@ | |||
/** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, this file just needs to be removed from this PR. it should instead import renderGraphiQL.js
as before, which does not contain any typescript, and uses the UMD global
</head> | ||
<body> | ||
<div id="graphiql">Loading...</div> | ||
<script src="./src/main.tsx"></script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove main.tsx
and instead point this to renderGraphiQL.js
as we were already doing. it will expect a UMD bundle w/ global GraphiQL
, not an esm module. This UMD bundle gets at least 700,000 downloads a month (that's only the stats for jsdelivr, we don't have unpkg stats)!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the HTML file should look like this, to simulate the CDN setup:
https://github.com/graphql/graphiql/blob/eab257ba3e65e47625216fc3545b56426e0c4e61/packages/graphiql/resources/index.html.ejs
I plan on coming back to this FYI! I have no wifi at home but now I'm at the office, so I may be able to put more time into helping you on this! |
I don't have much time before 05.01, work content must be delivered by the 30th(deadline), maybe I will have some time to deal with the 5.1-5.5 holiday |
If you like! Would it be ok if I made some commits this week if I have some time? |
Sorry it’s been a long time! But I would love to revive this PR and finish this up to help out the upstream graphiql2 and users who need more/ new formats. @jonathanawesome you may be interested in tinkering with this as well! |
Sorry, I haven't been motivated to do this since using Apollo explorer |
Hello @acao any plans to revive this? |
yes @shabab477 I was hoping someone would! just have not had time but was hoping to get to it in the next month or so. I would welcome any PRs towards a move to I would also be open to any monorepo tooling suggestions as well, rush, moonrepo, turbobuild, nx.dev, etc. if we can replace a monorepo-wide incremental build/watch dev experience like we partially have with typescript project references that would be awesome. We used to have project refs working entirely across the monorepo before i ntroduced vite to graphiql and graphiql/react in an awkward way. @thomasheyenbrock has done his best with this setup and made some improvements, but I would love to give him and other graphiql maintainers and contributors a much better experience! |
@rxliuli i hope it's ok if we re-open your PR for reference as we make the migration? |
Of course, feel free to use |
@rxliuli thank you and thank you for this helpful draft PR! I'm happy you found a tool that works for you. GraphQL is the only mission! |
@shabab477 let me know if and when you'd like to take this on! I am happy to help in whatever capacity, and am happy to schedule a time to learn about the repo if you have question. I just want to get a few more releases out to the LSP, and some fixes for graphiql@1 before i dive down this important but inevitably complex "rabbit hole" haha |
@acao I went over the repo. I'm open to work this weekend after my "usual" work 😉 |
closed by #3679 |
ref: #2323 (comment)