Remove build/three.js and build/three.min.js.
#25435
Conversation
|
This PR includes removing the |
Mugen87
changed the title
three.js and three.min.js.
|
Most libraries out there now are shipping 3 types of bundled units:
This PR is removing the 'global' bundle. Is there anything we need to update ? Looked like most of the examples are using ESM and importing everything under a namespace to look like the global bundle. |
|
My understanding is that the 'global' format is really pretty rare for published libraries, and we're one of few libraries still using it anymore. Would be curious if there are any statistics available from npm on use of these package.json entries, especially the |
Vue and a few others. Not advocating for keeping it. The use cases are "want to use cjs but don't want libraries populating the global namespace". Ultimately its all legacy. Sounds like the project has been moving in this direction for a while. |
|
Did a quick check: arabic, english, italian, japanese, korean, pt-br, russian, chinese The jsfiddle linked in those pages needs to update. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
mrdoob
changed the title
three.js and three.min.js.build/three.js and build/three.min.js.
mrdoob
changed the title
build/three.js and build/three.min.js.build/three.js and build/three.min.js.
|
What about adding minified version of
|
|
Does that mean it won't be possible anymore to grab the script from |
An alternative could be https://esm.sh/three@0.148.0 |
You can still do this with the ESM version. The import just looks a bit different https://jsfiddle.net/em4j9hvu/ |
|
Like others, my only use-case for these files was hacking together quick and dirty prototypes, but (as demonstrated above) most browsers support modules out of the box now, so happy to see those ~2MB removed from the library |
|
@Mugen87 I've asked twitter and I feel like we should keep |
|
I read the tweet. I'm confused. So the person who cant upgrade to a recent version for many reasons, needs 150 to keep a specific structure ? I'm also confused because they can get the same presentation for their code by changing a single line import to ' ... as 'THREE' ' and don't need to convert their client code to modules. Am I missing something ? |
|
I'm not sure... As far as I know, the only thing they would have to do is changing this: <script src="builds/three.js"></script>
<script>
// their code
</script>To this: <script type="module">
import * as THREE from 'build/three.module.js';
window.THREE = THREE; // make it global
// their code
</script> |
|
@jbaicoianu That doesn't work for you? |
|
Maybe we should add this example to the migration guide? |
|
I see. Well, I'm okay if we add a deprecation warning to the files. Can we define at least a concrete release number in the warning where the builds are going to be removed? |
|
Lets go with r160 (December 2023). |
|
Should I revert the remaining changes to |
|
Go ahead, go ahead. I'm done for today. |
|
@mrdoob when you remove |
|
Wait till you hear it from the source but, to put your mind at ease: The build system is the same for all file formats, removing one entry in the list of configuration does not remove the build system. You can add a few lines to build any format or custom ones at any time. Take a look at the changes in 25464 just above to see how easy this is. {
input: 'src/Three.js',
plugins: [
addons(),
glconstants(),
glsl(),
terser(),
header()
],
output: [
{
format: 'umd',
name: 'THREE',
file: 'build/three.min.js'
}
]
}Add or subtract the |
Can you specify what you mean with "all of the functionality to produce these files"? |
|
I guess he is referring to #20389. |
|
That makes sense but that won't break or change by removing a build format. |
|
When removing |
I think @epreston answered most of my question. When you remove the files themselves, will you also modify |
|
Nobody can give guarantees but its likely to go down the same way; Removing the two files that are generated and the 10 lines above that tell the build system to make them. If you want to be in the safest position, realise that making a build from a build is not the cleanest. If you are creating custom build formats from source, you would not be concerned about this. Transition to something where you are making exactly what you want. Hot tip: In that configuration, avoid If you link a github repo, happy to make a PR for that repo with the changes. |
|
@Mugen87 @donmccurdy @mrdoob I'm sorry to say it but I am feeling frustrated with the direction this is going (removal of all js build files). Like @jbaicoianu , it's not as simple as using @mrdoob 's pattern of making THREE a global on the window object after importing from a module. And unlike him, yes I AM that old-school: I have all my static js files lined up one after the other in the body of the HTML document (the way I've always done it for decades). The 1st one is three.min.js. So I tried @mrdoob 's code pattern and.. the problem just got shifted down to the next js file in the long list of my required js files, lol. I then tried making each of those into modules, having to manually add 'import' this and 'export' that everywhere. And after 2 hours spent (read wasted), I have nothing to show for it - my whole project won't even start. Now there are a lot of things I have yet to learn about programming, but by no means do I consider myself a beginner (coding in C and OpenGL 1.0 since the mid 1990's). I tried reading your landing page called 'installation', but that did not clarify the issue nor help me get started with the 'transition from static js to modules' process. Now if I, with decades of graphics and games programming experience, cannot get my single-page demos up and running, how do we expect a beginner programmer (who may be interested in trying graphics for the first time) to do it? Part of the magic and usefulness of the three.js library is its ability to remove friction from the graphics setup process. In other words, I can get from a blank screen (and a blank code editor) to 3D graphics on my screen in about 5 minutes (with the old way). That's what 0 (read zero) friction should feel like. And the way things are headed, I'm about to have to add a whole lot of unnecessary friction (possible build system? use and rely on npm?) and extra lines of code ('import' this and 'export' that), all...to do the same exact thing. :( Dinosaurs like me (who still use static js files all located in the same js folder) may be on the way out, but I'm just thinking that there might be potential beginning users of your library out there who will feel lost, unless they know about build systems and modern ES6 modular patterns. And even if they are more experienced, I'd wager that there are others like me out there who prefer having the library as a neat, static, minified js file that they can just include in their project with 1 line of code. That is truly 0 friction. *Edit: Isn't there some sort middle-ground we could aim for? Or is it really a mutually exclusive situation, where you either have downloadable builds (and somebody to maintain that process of building each version, I realize) , or pure modules, but not both at the same time? |
|
Are you open to respectful but direct feedback ? |
|
@epreston |
|
Doesn't <script type="module">
import * as THREE from 'build/three.module.js';
window.THREE = THREE;
</script>
<other script tags>work for you?
What is the problem? |
|
Context:
Things that support what you wrote:
Here's the issue:
So all up:
|
|
@LeviPesin I used this bare-bones Cornell Box scene to see if I could get the 'window.THREE = THREE' pattern working. It looks like that initially works, but then PathTracingCommon, InitCommon, and Cornell_Box js files all start complaining in the console. At this point I was confused because putting 'window.THREE = THREE' in the 1st script should globally define THREE, right? Yet PathTracingCommon and InitCommon both said THREE is not defined. I tried making them modules too and importing/exporting, but then there are certain functions that I define inside InitCommon (like init(), ha), that Cornell_Box.js then complains about - 'Init is not defined'. Thus it becomes a game of cat and mouse, trying to chase down every last dependency between several js files. I realize that the latter part of that problem is probably due to the way I organized the InitCommon.js file vs the demo files (like Cornell_Box.js) that rely on it, and that's on me. Also, although I really appreciate the help, I don't want to derail this thread too much into a help forum-type post where we debug my personal problem. I would be glad to continue something like that on the three.js-preferred Questions discord forum with a tag related to ES6 modules. At any rate, thank you for taking a look. :) |
|
Put the three.js script tag in your header to get it to load before others in the body to resolve this issue. There's different places you can include the script. There's a few options to explore there. |
|
@epreston |
|
@epreston Re: script tag in header, |
|
Seriously mate, lets get you setup for success. You open to PR's on the project ? |
|
I appreciate that, but with that big of a shift on how things would work, I feel that I need to come to terms with it and totally understand what any new code is doing and how the system works, on my own first. One of things I've grown comfortable with is that I can randomly pick a line of code from any of the thousands of lines in my project, and I can tell you exactly why it's there and what it's doing, and how it relates to the system as a whole - now of course this excludes files like GLTFLoader.js, which I just merrily use without knowing how it does all of its magic, lol. But for anything that I create, or pull into the project, I need to really understand it first. That was my long way of saying let me see if I can gently introduce some of the more modern techniques, and then once I understand the system more clearly, we can discuss larger changes. Thank you again for your thoughts and input. |
|
Case in point, I just got mrdoob's pattern to work, with the help of your suggestion about putting it in the head! Although when I first tried it just now, it gave me the same errors in the subsequent js files. I had to make a small addition to this quick fix. For some reason, I remembered the keyword 'defer' floating around in my head (maybe from some article I read, or on a forum somewhere). But anyway, when I simply added 'defer' to the subsequent js files script tags: <script defer src="js/PathTracingCommon.js"> </script><script defer src="js/InitCommon.js"> </script> <script defer src="js/Cornell_Box.js"> </script> It worked! :) Thank you again for this quick fix. I know it is more of a band aid right now for my larger structural problem of the entire repo, but just getting this to simply work without a lot of fuss and extra code, has inspired me to go further! Thanks again everyone for listening to my concerns and for your help and patience. |
|
@erichlof here's another idea from a mutual dinosaur: I do a custom build of https://github.com/paulmasson/threejs-with-controls If that's sufficient for your needs feel free to use it. You can also add additional components from the examples rather easily by modifying one file. That way you can have whatever you want without friction. Cheers! |
|
Thank you Paul! Yes, in the past, I thought of doing my own custom build with just the components I need. But as you know, that takes time and effort that I could be spending elsewhere on the project. I might give your build a try - thank you for letting me know about it! :-) Also, as mentioned above, I got the modular system working just last night (with the help of the friendly people on this thread), so maybe I can dig deeper into that system and, using the more modern ES6 way, 'import' only the necessary components. I definitely don't need all of three.min.js I realize, but it's just so easy to continue to include it as a static script in my HTML file, that that's what I've defaulted to over the years, I guess. But there's always room for improvement in loading efficiency of my project over the network, so I am open to trying some different solutions to see which one I can get up and running without too many changes to all the files in my codebase. |
Related issue: #25341 (comment)
Description
This PR removes the builds
three.jsandthree.min.jsfrom the repository. The motivation behind this change is explained here: #25341 (comment).