Would it make sense to add support for a .jlignore file for the new package server scenario? One could use that file to exclude files from being deployed to user machines when a package is downloaded via the package server.
VS Code extensions have a similar model: during dev, the extension is run directly from the folder where one cloned the extension repo. But when the extension is installed via the marketplace, a lot of files from the original repo are not included, namely everything that is listed in the .vscodeignore file.
Things that one might want to ignore are the docs folder, folders with some dev time scripts, all the CI/tool config files. Some of this might reduce the size a fair bit, e.g. images or videos in the docs folder.
Is the idea that this file would mark some parts of the package repo for not being included in the tarball that gets installed on the client system? If so (and it's decided to be good idea), it seems like having a stanza in the project file would be better.
Would decouple the tree-sha of the git tree with the tree-sha of the tarball. Whats the problem with including some extra files in the tarball?
Yeah, I'm skeptical that this is a good idea myself. It would make it impossible to dev packages or acquire them from github since the actual content tree of the installed package would no longer have any connection to what's in the git repo. Either that or the content tree is that of what's in the repo, but then it would be impossible to verify that the downloaded content is what it's supposed to be and we can kiss all the benefits of content addressing goodbye.
I don't think this will happen due to the way we content address things. Large videos in a git folder is a valid concern but you generally don't want to track those via git anyway.
Most helpful comment
Would decouple the tree-sha of the git tree with the tree-sha of the tarball. Whats the problem with including some extra files in the tarball?