Packages are typically different once published than they were inside their original repositories. Call it transpilation, build, compilation, packaging, etc, most popular projects require some level of support for dynamic code execution before reaching their usable state.
As much as I'd have liked Git to be a viable option compared to centralized registries, last couple of years demonstrated running arbitrary commands during install is too much of a risk for it to work at scale.
...most popular projects require some level of support for dynamic code execution before reaching their usable state.
None of your examples require arbitrary script execution. You can specify them all declaratively, like Bazel forces you to do. I don't think that package managers should be doing the job of a build system though.
I don't doubt that 3.x probably has worst perfs (it's almost two years old now), but just to clarify we closely track performances and Yarn and pnpm and pretty much on similar level:
Eh, easy to say. Remember how Sourceforge started shipping ads in binaries people downloaded? If you think failing was the worst scenario, you lack imagination.
Of course. Modern Yarn releases (4.x) are deterministic to a fault and you can rely on it to have a consistent behavior across your whole team. As for feature-wise I'd say it's a lot of small details that together add up once you grow used to them.
The next major release will keep pushing in that direction with both better performances and features we couldn't implement until now due to their reliance on said perfs improvements.
As mentioned in the issue you link the problem comes from third-party packages with non-deterministic build scripts in git dependencies, or files on disk being actually different (although I guess we could at least try to normalize crlf, but as you can guess it will break someone).
Curious how you did this; I looked into that couple of months ago but even with custom hooks the Python injection points seemed to limited due to the internal resolution cache.
Isn't Godot a little ill-designed to work well with LLMs? for example I ended up a couple of times with incorrect tres files, and letting the llm generate IDs feel a little fragile.
I don’t think Godot is any worse than other engines inherently, other than it moving forwards pretty quickly and the latest versions not being in the training data.
I wanted to evaluate which engines would be the best for working with LLMs in and it seems like Flax and Stride kind of come out on top - the former has a lot of stuff out of the box (including terrain) and the latter is all C# basically which is great for debugging. But either way, the source code for both of those makes the functionality a bit easier to track down compared to Godot (which is a lot more complex internally).
So what I do now is have both the engine source code locally alongside the docs and when I want to implement something with AI I just tell it - look at the docs, then at the source if needed, write tests for our code, if something doesn’t work then edit the engine source code in our branch and use the provided convenience script to rebuild the engine (both of those are also pretty fast, I ended up settling on Flax, plus the component model is closer to Unity which I like).
I don’t ask the AI to create scene files though, or any sort of visual assets, but rather stuff like RTS/simulation code. I don’t think any AI is that well optimized for the 3D work outside of simple proof of concept setups.
I had very few issues, sometimes I had to direct CC to the godot docs and we could keep moving. Specifically the tile configuration was a "read the docs" moment. All the functionality is available through code, so nothing CC can't reach afaik. Is there any LLM oriented game engine?
I have taken many stabs at it and Claude will produce stuff but the output is very far away from useful. E.g. "I've created a road and beautiful trees" and what I see is a mess of colors and shapes.
I concur it's bad at directly visual concepts, your prompt is akin to the svg pelican. What I do is asking him for procedural algos, automatas, quadtrees, layered noises, and rig those into the game. Yes, it can't "make the next gta", but with a reasonable scope and knowing what it does best, it has been very easy for me to produce satisfying results.
My problem is I don't really have video game engineering experience. I was going off a concept that a different AI nailed with video creation and was trying to replicate it in the game engine.
Sure! Two are gameplay pics. An enemy sprite sheet generation, and the results of the map generators. Of course these are basic placeholders for a few hours of work, but I will definitely go heavy on this route with more layering and details.
Bevy is a great engine for LLM-based games because it's 100% code. I'm toying with a few things in it, one of them is an entire-planet economic simulation, and it scales well up to a million dead tiles and 10k-50k live tiles on Apple Silicon, pretty impressive.
I have a simple script system in my editor that is designed to let the chatbot (Claude) to work on the content. The script interface lets it to import assets into the project, open them for editing, take a screenshot, export content (and few other things). All data is in JSON so it typically figures out the data format quite fast and easily.
Here screenshots of some UI styles that it generated.
It's not about the package manager, it's about the runtime. Python isn't able to support this pattern with its resolution pipeline, so package managers have to resort to do the work to dedupe versions.
By contrast Node.js has built-in capabilities that make this possible, so package managers are able to install multiple versions of the same package without that issue.
It's not just that, it's also a filesystem layout issue. If you install everything in `/usr` or `<venv>/lib/pythonX.Y/site-packages` you cannot have two versions / variants of the same package installed concurrently.
For that you need one prefix per installation, which is what Nix, Guix, and Spack do.
The runtime can also use mount namespaces to support concurrent installations. Or, if there is a compilation step, the linker can not expose symbols for clashing libraries and just resolve them within the dependency chain.
The package calculus allows all of these to specified cleanly in a single form.
That's relatively infrequently - TabNine offered me accurate completion while still writing my code, whereas with Copilot I not only have to wait for it to return the answer, I also have to hope it knows an answer. If it doesn't, too bad, lost time for nothing.
The article doesn't go into how to integrate TypeScript in the monorepo for development - what we do on the Yarn repository is that we point all the package.json `main` fields to the TypeScript sources, then use `publishConfig.main` to update it to the JS artifacts right before being published.
This way, we can use babel-node or ts-node to transparently run our TS files, no transpilation needed.
By this are you saying your “app” project is the one that actually transpiles the TS from your shared packages?
Wouldn’t that mean the shared packages tsconfigs aren’t respected if you changed something like strict options? And also that a clean build of the whole monorepo is going to recompile each shared file for every app project rather than just once?
Yeah, I would be interested to hear from others how they accomplish this. I played around with Nx and it uses TypeScript project references. It is a lot of boiler plate to set up every time you want to create a new app or library. Fortunately, their generators do this with one command.
In the past, I'd put a "typescript:main" field in package.json and configured my bundler to prefer that field. I gave up at some point - probably when I migrated to rollup.
Moving forward, I'm going to use wireit for these things. Pure modules get built with tsc. At the highest level (e.g. where it needs to be embedded in a page), make a bundle with rollup.
wireit has two nice properties: incremental building and file-system-level dependencies. Within a repo, you can depend on ../package-b. However, if you have multiple monorepos that often get used together, you can also depend on ../../other-project/packages/package-b. No matter where in your tree you make changes, wireit knows when to make a new bundle.
I've just started with wireit (it was only launched recently), but it seems to be a nice solution to wrangling dependencies between related JS libraries.
