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.

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

scripts: add s script (as a faster start option), allowing very fast demo building when developing #1003

Merged
merged 3 commits into from
Nov 4, 2021

Conversation

peaBerberian
Copy link
Collaborator

@peaBerberian peaBerberian commented Sep 9, 2021

What this PR does

This PR tries to improve demo building time by using the notoriously faster esbuild bundler instead of the Webpack bundler we use by default.

I also profited from this PR to improve on the current webpack config scripts by making them configurable through command line arguments instead of environment variables. This should be easier to understand and follow. That part can (and most probably should!) be added in a separate PR.

By switching from webpack to esbuild when starting a demo, we go on my laptop from 15s-16s to 100-200ms to build the demo page.
16 seconds was not much, but it was enough that it could lead me to switching to another task, waiting for the demo to be built - and thus usually costed much more than that. I would not be surprised if I was the only one in that situation.
With sub-second results, a code modification can be tested instantly.

By making demo bundling close-to costless, it could also improve the time of the bisect operations we sometimes (arguably very rarely) perform and it allows nice new usages like testing multiple demo versions easily.

We could go even further by using something like open to open the developer's default browser on the demo page directly (of course more advanced testing will need to test on multiple browsers, but we're talking about fast checks here).

Because I did not want to take the bet - and because there are some disadvantages in using esbuild - I still left Webpack by default when running the npm run start script. esbuild is only used when using the npm run s.

Webpack is also still used when generating the demos for production, the tests and the legacy builds (dist/rx-player.js and dist/rx-player.min.js). Switching to esbuild for those could be possible in the future, but Webpack is not a pain point in those cases for now (considering tests are long anyway and the others are rare occurrences).

Disadvantages

No type-checking performed by esbuild

Among the disadvantages in using esbuild, the main one I found is that unlike Webpack, esbuild cannot be used to type-check the files while they are bundled.

At first, I tried to write a script performing both in parallel (bundling and type-checking) to emulate the current npm run start behavior, but as it turns out TypeScript did multiple things that made this experiment a pain:

  1. TypeScript's JavaScript API is both unstable and incomplete, so I could not just write a simple Node.js script handling its output in a simple and straightforward way like we do for webpack
  2. tsc binary's watch option - which I wanted to use here - clears the screen and adds many line breaks by default, making it harder to making it cohabit with a second script displaying on the same output.

So for now, I only added a supplementary npm script, npm run check:types:watch which performs type-checking while watching the files it type-checks (something we might need anyway).

It is a supplementary dependency

Another thing I do not like is that it is a supplementary dependency which moreover is totally optional.
Thus it adds maintenance cost and also 7MB to the project which leads to approximately a 3% size increase of the node_modules directory.

This is not much at all but I still tried to make that dependency "opt-outable" when npm installing by e.g. making it an optional dependency.
However, turns out only optionalDependencies exist, and not optionalDevDependencies like we would want.

An old issue seems to have been created about that on npm's issue tracker, npm/npm#3870, but the conclusion seems to be that this is both complicated to write for them and not an important enough feature.

But in truth, I recognize that this is kind of an overengineering need.
3% increase of the node_modules directory is nothing and this dependency only has an impact on locally built demo.


What do you think?

Do you think reducing demo building time is even a real need (I won't be angry if you don't :D)?

@peaBerberian peaBerberian added script Relative to the RxPlayer's scripts (e.g. build scripts, release scripts etc.) dependencies Pull requests that update a dependency file labels Sep 9, 2021
@@ -1,4 +1,4 @@
import RxPlayer from "rx-player";
import RxPlayer from "../../../../src/index.ts";
Copy link
Collaborator Author

@peaBerberian peaBerberian Sep 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

esbuild doesn't do alias directly. It relies on jsconfig.json (apparently a VSCode config file!) and tsconfig.json files that can define it for it.

However I did not want to add yet another config file at the root for what is moreover only a demo need.
So I went back to relative imports, which are exactly the same thing.

*/
function generateFullDemo(options) {
const shouldMinify = options.minify === true;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved webpack-demo.config.js here

* taken to allow code coverage reports.
* @returns {Object} - The Webpack config
*/
module.exports = function generateTestWebpackConfig({
Copy link
Collaborator Author

@peaBerberian peaBerberian Sep 9, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved webpack-tests.config.js here

@peaBerberian peaBerberian force-pushed the misc/esbuild branch 2 times, most recently from e60c533 to cbf7232 Compare September 15, 2021 12:50
@peaBerberian peaBerberian changed the title scripts: add start:fast script, allowing very fast demo building when developing scripts: add s script (as a faster start option), allowing very fast demo building when developing Oct 15, 2021
@@ -54,6 +54,7 @@
"prepublishOnly": "npm run build:modular",
"standalone": "node ./scripts/run_standalone_demo.js",
"start": "node ./scripts/start_demo_web_server.js",
"s": "node ./scripts/start_demo_web_server.js --fast",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is any reason why it is named s? Make it harder to reason about what about start-fast?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I updated it because if the main point of this new script is to perform very quick checks, it made more sense to me that the script's name was not longer to type.

minify: false,
production: false });
} else {
slowBuild({ watch: true,
Copy link
Contributor

@PaulRosset PaulRosset Oct 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is something very minor but I guess the script is not slow this is just esbuild that kill the competition :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah it's to create a clear dichotomy with the "fast" one!

const minify = !!options.minify;
const watch = !!options.watch;
const isDevMode = !options.production;
let beforeTime = performance.now();
Copy link
Contributor

@PaulRosset PaulRosset Oct 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that nodejs need that dep to use performance:

Cause I got that issue on Nodejs v14.15.1

image

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might depends on the nodejs version yes.
On mine it is available without importing perf-hooks.

But more interestingly, the verified answer from your stack overflow, talk about process.hrtime. However, the nodejs documentation isn't explicit on if this is a monotonic clock :/
I will check. At worst, it is only used for time indication to the user, no biggie if it isn't that coherent when the clock is updated !

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@PaulRosset
Copy link
Contributor

I see a real use case and a real benefit for developers working every day on the project.

@peaBerberian peaBerberian merged commit fe71ab4 into master Nov 4, 2021
@peaBerberian peaBerberian added this to the 3.26.2 milestone Nov 9, 2021
@peaBerberian peaBerberian deleted the misc/esbuild branch December 3, 2021 15:36
@peaBerberian peaBerberian mentioned this pull request Dec 16, 2021
17 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file script Relative to the RxPlayer's scripts (e.g. build scripts, release scripts etc.)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants