Release JSIL to NuGet

[iskiselev]

I think it will be very convenient for other if they can simple install JSIL using NuGet.
I currently test it with my private JSIL build/private feed. I created three packages:

• JSIL.Compiler - contains output from bin folder. Also will contain target, that would be executed on build process.
• JSIL.Meta - contains only JSIL.Meta.dll
• JSIL.Libraries - contains Libraries, that should be installed on Project that will contain html file.

I have only one unresolved issues. Really, all this three packages depend on each other version, but as they should be installed in different projects, I can't restrict that they version be same.

[kg]

I don't have any interest in distributing binary releases of JSIL; it is purely a developer tool. I think if I were to simplify installation it would be by distributing prepackaged linux VMs that contain mono + necessary support libraries + a JSIL git checkout.

EDIT: Naturally, this is not currently possible because the Mono developers take years to ship basic BCL container fixes...

I also am uninterested in splitting them into separate packages. They're not intended to be separable. Compiler relies on Meta on purpose and JSIL output is not intended to work without JSIL.Libraries. You need the libraries for JSIL and not just for output projects, because they are used by the automated tests.

[kg]

Pulling the XNA profile out into a package is a good idea, though.

[iskiselev]

Let me describe you my use case example.
My project is developing by a team and we have continuous integration server. Not all team member involved in development of all parts of our application. At the same time we want every developer can build and run application, same as CI server. One additional bad thing - we use SVN as source control.
So, for integration JSIL I have group of options:

1. Every developer update and build JSIL themselves. First problem here - we need share additional knowledge between every team member (some of then never right any line on client!). Second problem - we make some tweaks specific for version of JSIL, so all team should upgrade JSIL same time.
2. Use sub repositories, that will track JSIL version to checkout - but SVN can't use git subrepo, so we need mirror GIT repo in some ways (honestly maybe we even can work with this way, as github has svn mirror - but JSIL have subrepo itself, and github create mirror only for first level repo, so even here I have some troubles).
3. Save binary JSIL build inside our repo. But saving binary dependencies inside source control is not a good practice, I think. Besides, on every JSIL update we will push very big (in byte size) update to repo, that is also not good.
4. Install JSIL right in our project using NuGet. In this case, project contains information, what specific version of JSIL they should use just as one text string. Visual Studio / Nuget will download package with proper JSIL version on first build on every developer computer, if it was not installed yet.

Really, NuGet is a repository specially created for binary reference / developer tools. For example, you can find ILMerge there.
If you agree on NuGet support, we could discuss how should (if should) we split JSIL for it.
At the same time, I understand, than when you don't provide binary JSIL release you close JSIL from some group of people, that can't build it themselves from GIT, so they want ask silly questions :)

[kg]

The core problem with binary releases of JSIL is that they create the appearance that it will be usable by people who can't use git. It's simply not that kind of product at present; maybe it will be eventually, but it doesn't have that type of maturity yet: the documentation isn't that complete, it will throw exceptions that only make sense if you look at the line of source they're on, and bugs you run into will get fixed by a git commit instead of the next binary release coming in a week.

I can see how your issues are troublesome though. I'll give them some more thought, but off the top of my head:

1. The solution to this is to have your own branch and pull it down. You don't have to put binaries in there, you can just have a revision-controlled folder containing the code for the rev of JSIL you use + its dependencies. This shouldn't be TOO difficult in either svn, git or hg, but maybe I'm overlooking something. People shouldn't need to know anything about this; the external/submodule gets pulled down as part of the revision control step, and your build steps invoke msbuild on JSIL and then invoke JSIL on your application to generate JS.
2. Yeah, submodules are a pretty poor solution, as are svn externals. I'm not sure how to address this. Hg isn't any better in this regard.
3. I agree that storing binaries in your repo is a bad idea.
4. If this is the most straightforward solution for your team, definitely use it. From my perspective it adds additional complication/dependencies so I'm not super happy about it. I don't know if I'd ever merge nuget support but I don't have anything against someone offering it, and if there are simple steps we can take to make JSIL compatible with NuGet I have nothing against doing that stuff - I just have no intent to merge changes that make JSIL NuGet-only because that will make it actively harder for me to develop it.

[iskiselev]

Okay, thank you for explanation your vision.I fully agree, that with NuGet publication here will be much more questions from people, who can't use JSIL on this stage of its' development.
Really, I've already solved all my team problems with my private branch of JSIL, that is building by our CI server with pushing NuGet artifacts to our private feed.

I think, that I even will have time to prepare public quality NuGet package. But here is one problem. When I look on NuGet, I have security/trust questions to NuGet package publisher (as it is application that will run on my computer). So, usually I trust to author of library (especially if it is distributed in binary form - I already use it in this case). It is not so trustful, if package was prepared/published by person, other than source owner/source owners team member.

In other words, I may work on preparing NuGet packages, I can suggest them for discussion here (I can take some feedback how we can make them more usable), but I won't publish them myself on NuGet public feed.

[wasabii]

Tons of stuff on NuGet is kind of broken. It's pretty much expected. Think of it this way: it's advertising. Some developer might be searching NuGet for "C# to JavaScript" or something, and stumble onto JSIL, and try it out. And then find out that it errors in his particular case. And then get the source. And then fix a bug.

It's been known to happen. ;)

[iskiselev]

Probably JSIL should also copy Libraries scripts to some target folder during translation process. It will be really good, as we may control over used Libraries version (translated/stubbed/ignored) in translation, when we now all information from config.

With it we end with only two packages: JSIL (with binaries and build targets) and JSIL.Meta.

[iskiselev]

Will be partially resolved with #1013, still need to create JSIL.Meta package.