-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Using esbuild instead of rollup #1298
Conversation
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 PR mostly LGTM, although I don't know enough about JS tooling to make an informed call: but if you are confident that the end result is the same as before, I'm happy with it.
However, I think there is a problem: I tried to deliberately put some mistakes in the .ts
files but the build doesn't complain.
E.g., I tried to apply this diff:
diff --git a/pyscriptjs/src/main.ts b/pyscriptjs/src/main.ts
index cd442cb..73d30ec 100644
--- a/pyscriptjs/src/main.ts
+++ b/pyscriptjs/src/main.ts
@@ -59,7 +59,7 @@ More concretely:
*/
export class PyScriptApp {
- config: AppConfig;
+ //config: AppConfig;
interpreter: InterpreterClient;
PyScript: ReturnType<typeof make_PyScript>;
plugins: PluginManager;
@@ -168,9 +168,12 @@ export class PyScriptApp {
// point (4) to point (5).
//
// Invariant: this.config is set and available.
- async afterInterpreterLoad(interpreter: InterpreterClient): Promise<void> {
+ async afterInterpreterLoad(interpreter: number): Promise<void> {
console.assert(this.config !== undefined);
+ this.I_dont_exist();
+ aaa();
+
this.logStatus('Python startup...');
await this.interpreter.initializeRemote();
this.logStatus('Python ready!');
But npm run build
doesn't complain:
$ npm run build
> pyscript@0.0.1 build
> node esbuild.mjs
pyscript (prod) built in: 132.779ms
@antocuni I believe esbuild doesn't bother with TypeScript/JS possible errors, likely the reason is faster than others. We have all hooks and linters and prettifiers and tools ahead of commits, which I think (correct me if I am wrong) would already prevent shenanigans down the CI pipe. My thinking here is that if we are defensive on pre-hooks, CI, linting, TS-test/check, prettifier, and whatever else, we shouldn't really demand the bundler to be in charge of all these early errors already visible and caught before the bundler even run ... so we have two options:
I am more into the second option kind of developer, but I understand where you come from, although minification in isolation is to me a step too late to expect warnings around the correctness of the code ... we have other tools for that. |
@antocuni as discussed in discord I've put |
Perhaps this is is an issue in my environment, but neither make dev
This stackoverflow post implies this is an issue with node v14+ (I happen to have v16.13.1); some fixes also proposed there. npm run dev
Not sure what's going on here - I've tried running |
From the esbuild typescript recommendations, I'd proposed we add There seem to be only a few patterns this precludes, none of which we use, like re-exporting an imported type. I should say - this is really awesome work, and I'm very much looking forward to the build speed improvements! |
I love ESBuild, this is worth doing. 👍 |
@JeffersGlass I think the recursive issue is due nodejs LTS not having that ability ... shame on me I've tested on node 19. The second issue might be due usage of |
@JeffersGlass I've moved to CommonJS to be sure the path is well enforced everywhere without using latest ESM features but the I have also created a recursive function to watch recursively so no error should be shown there. Am I assuming correctly LTS 16 is the minimum version of Node? Can you please verify everything is working now? Thanks! |
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.
LGTM!
FWIW, npm run dev
works on my machine with node 18.5.0.
@WebReflection I think this is ready to be merged, unless you have other edits to do. I'll merge it as soon as the build is green (ping me if I forget 😅) |
So UPDATE - it does work, but needed to run SECOND UPDATE - See below.
|
Second Update: both Check out the terminal copy below - this is just adding some extraneous spaces to a single file and resaving. It rebuilt successfully twice, then crashed on copy. Like I say, I hope this is just a me-problem, but I am baffled.
|
I am afraid I am very confused here ...
The CI is using 18 LTS but I've tested in 16 LTS and I can never reproduce what you are seeing ... which makes me think that this is the case:
but I'd love to get to the bottom of this. edit FYI if you are on 14 LTS it's almost at its end of life https://nodejs.dev/en/about/releases/ |
@antocuni after all it looks like the |
this is a bit worrisome. I wonder whether it has something to do with your IDE or with esbuild itself.
This forces the rebuild 10 times in a row. On my machine, it works reliably:
@JeffersGlass what is the file that you are editing? Is it the same file that |
yes, those are needed for sure because they are fetched/imported by pyodide at runtime. Sorry for not being clear about that. |
I suspect my initial impression was wrong - Cloning this branch fresh, I am unable to reproduce my issue. That is to say, the following steps/commands leaves me unable to reproduce my earlier issue, and additionally, running your shell loop builds successfully many times in a row.
Running your test on my original copy fails immediately the first time the loop touches main.ts. It is complaining about "no such file or directory" at "pyscriptjs/build/index.html", though that file does exist on my machine. Same issue as copied above:
So at least it's not a reproducible issue in a fresh copy; almost certainly something odd happening in my environment. |
good, this mean that we can proceed with the merge. At the same time, the nerd which is inside me would be really curious to know what is causing the issue in your old environment. Probably not worth spending time on it, though :) Cool, so I'll proceed an merge this! |
Description
This PR migrates building tasks to esbuild so that it takes ~100ms instead of 6 seconds to create our artifacts.
Changes
./src
folder that kicks in esbuild when changes happenmake build-fast
entry in Makefile and removednpm run build-min
form thepackage.json
Checklist
docs/changelog.md