@Symbitic
i really appreciate the effort and hard work and research you’re contributing to babylonjs, and i love these kinds of discussions – i think this discussion will bear fruit and lead to a much leaner and meaner babylonjs@5
For why not use tsc to generate ES6: It’s not “why not generate UMD from webpack and ES6 using tsc?” It’s “Why not generate UMD, ES6, and DTS using just rollup?” And the answer to that is: it’s simpler. Plus, rollup is faster.
tsc can generate the es modules, and generate the umd modules, and the .d.ts files — what do you think rollup is adding to the situation? only more complexity
You keep asking over and over why we don’t just use tsc for ES6. And my answer is this: “Do you prefer to use Webpack for UMD and TSC for ES6, or would you prefer to use Rollup for UMD and ES6 at the same time?”
i want to use tsc to do all of it. neither rollup nor webpack has any place in the library, and has nothing to add
- es modules – tsc does it well
- umd – tsc does it well
.d.ts – tsc does it best- there’s nothing else desirable that rollup can provide
what’s important, is that the users can then take our modules, and then use them with rollup or webpack in their own app’s build – otherwise they can use a convenient pika url to instantly get an optimized bundle from any module as an entrypoint – that’s a big evolution that isn’t just going to “go away”
with these emerging best practices, modern libraries don’t offer bundles, just the same as they don’t offer minification – these are optimization concerns that are best left to the consumers
many users are already using rollup/webpack/browserify or other bundlers in conjunction with minifiers in their own app’s build – it’s totally redundant for every modern library to also provide minified bundles – the user’s bundler will bundle and minify the code that has already been bundled and minified – it’s pointless
and for even more convenience, the user can grab an optimized pika bundle (pika is unpkg for bundles!) – or better yet, just use direct es modules for development convenience
in this new ecosystem, there’s no important reason to use any bundler, or any minifier, in any modern library’s codebase – rollup and webpack have nothing to add but the complexity in their own configuration files, and is best left for consumers to control
we’re already going to have one tsconfig.json, and in my opinion, that’s already more than enough complexity (but i love typescript and wouldn’t take that away!) – the last thing we need are more gulp/rollup/webpack configs floating around
You do NOT want something like import {Mesh} from "babylonjs/dist-umd/core/mesh.js" - Ask RsJS, it is a mess to maintain. You want to use ES6 modules to import specific classes (UMD does not support tree-shaking.
of course, i mean nobody should want to use umd for any reason – es modules is the sacred best practice of the future – however there’s nothing intrinsically wrong with supporting legacy systems in a deprecated way
@Symbitic – one thing i really agree with you strongly about, is that we should remove all of the gulp stuff and the entire Tools/ directory – babylon shouldn’t be so complicated as to necessitate a whole directory of “custom build tooling” – there should just be a simple handful of industry-standard one-liner npm scripts like all of the other modern libraries
i also agree that the current complexity of the babylonjs repository is a major obstacle in attracting contributors
@sebavan
[…] (terser has been the default in Webpack since a while now) […]
i can see that you folks are getting all caught up in the old bundling mindset – you’re still hung up trying to work out solutions for problems that no longer exist
i think it will take awhile for it to sink in, but let’s step back: bundling is outside the scope of a modern library – these days, users can use their own bundler, otherwise they can conveniently use a magic bundling cdn like pika’s – this means we’re finally in the era where a modern library author can simply supply the universal format, es modules, and leave out all of the complexity (that’s not lazy, that’s a best practice because it’s so simple!) – at this point i’m just evangelizing for the modern ecosystem, but people on the cutting edge like pika’s team has plenty of reading material on the subject of emerging best practices
that all being said, i think it’s reasonable to include the legacy entrypoints, like the bundles, deprecated but present for legacy users to keep using their familiar workflow unchanged – i do however, think that legacy support should be achieved through a few simple npm one-liners
now, i really want to address the perceived obstacles in taming babylon’s complexity:
- Checks circular dependencies
- replace with a simple test suite
- Lint (we will move to eslint soon)
- Typedoc
- Validate typedoc
- what validation? of docs? doesn’t make sense, discard this complexity
- host the build (smallest portion)
- what do you mean “host the build”? i’ve never heard of this, discard this
- do you mean “deployment”? that’s a ci concern, or maybe an admin’s bash script
- Generate our playground intellisense files
- this is already handled by
tsc, discard any custom handling here
- Generate our .d.ts bundled/module bundled/and ES6
- already handled by
tsc, discard any custom handling here
- Extra Validation for imports and other custom rules
- simple typescript codebases don’t need this, discard it
- non-standard validation is an anti-pattern, discard this complexity
- handle the switch from our npm distribution
- what is this switch? discard this complexity
- runs our tests (units/integration)
- prepare local npm folder for publishing or local dev with npm link
- discard this complexity, publish a simple package like other modern projects
- discard any custom tooling around, expect devs to use standard practices
- tests our npm packages
- use a simple
npm test one-liner, discard any custom tooling for this
- ensures the es6 minimum package does not grow too much
- there is no “bundle size” worth considering, everyone just uses the modules they need
- otherwise they use an optimized bundle with treeshaking
- we don’t live in a world where bundle/package size is a concern anymore, because we don’t ship bundles anymore
- Run our local dev server
- one-liner:
npm run start – i suggest using the serve cli
- Ensures a full compatibility between the generated map files and VsCode as it is our primary dev tool
- i’m a vscode guy too – discard this complexity, tsc already does this
through all of that, i see perceived obstacles, but no actual obstacles – all of the perceived obstacles are from another era, and quickly disappear once you embrace modern best practice workflows
note: when i say “one-liner”, i don’t just mean that it takes one line to execute the command – i mean the whole command should be implemented in a single line.
for example, to start the dev server, we’d do npm start
the start npm script would be implemented with this one line: serve dist – this launches an http server for the dist directory – every script can and should be this simple – the compile script can simply run tsc – the docs script can simple run typedoc, etc – we don’t need big custom scripts for all of this, we can just use industry-standard tooling
finally a prepare script should run all of the smaller scripts, eg, using run-p from npm-run-all (a great little tool!) to run each script in parallel to make it run really really fast
"prepare": "run-p compile lint docs"
The full build is mainly intended for release not necessarily for daily development.
i really think it’s an anti-pattern to have a one build for local development and a different build for release
with the emerging best practices, there should be only one build – it’s the ideal build for both situations – and it runs really fast – and it’s super simple because it discards/outsources all of the complexity
i think this discussion will lead to a much more lean/simple/approachable babylon codebase
i am happy to contribute and help draw up a plan for a dead-simple babylon that everyone can understand and work on together
let me know what you folks think
Chase
