.cs -> .js Dependent Files

[Mike-E-angelo]

One of the cool things that I appreciate about TypeScript is that it provides the generated .js file from a .ts file as a dependent file (that is, a child file -- much like a code behind in an aspx) in the Solution Explorer. This is great as you have direct coupling with the file and you don't have to go digging around for a file on the file system.

Might it be possible to incorporate this functionality in Script#?

[nikhilk]

The generated script file (per project, not per source file) is in the bin\Debug|Release folder. By default this is hidden in the solution explorer, but if you turn on Show All Files, it will be visible.

Are you suggesting it should be made visible? There are things you can do in msbuild to cause the generated file to be added to the project (this is how the reference to mscorlib.dll is added in scriptsharp.targets) ... but where would/should the generated scripts show up?

[Mike-E-angelo]

Ah... no, what I'm suggesting is to do what TypeScript does with its .ts files, what ASP.NET does with its aspx/aspx.cs files, and what WPF does with its xaml/xaml.cs fies. That is, when you add a new "Script# Code File" to a project, it adds a .cs file, with another .js file "attached under" it. That JS file is what gets created when the .cs file is saved and/or the project is compiled. The build process is then just a matter of collecting all the assembled .js files, combining them into one file, and then minifying them into a single .js file (or dare I say Script# Assembly? :)).

That Script# Assembly is then what is added to a project when a Script# Assembly reference is made.

[nikhilk]

The input to the compiler is a set of c# files. The compilation and script generation does not happen per file ... it happens at the project level. In fact other than error reporting, the compiler doesn't even care about individual files. Think about scenarios like code in one file referring to code in a sibling file, or even partial classes. The compiler generates multiple script files for each set of sources - specifically happens to be a cross product of flavor (normal, minimized, test) and locales (for each locale-specific resx in the project).

As such the mapping is not 1:1 but rather N sources:M scripts or 1 project:M scripts.

[Mike-E-angelo]

Hmm... OK. I see what you're saying. I appreciate your patience as I try to wrap my mind around all of this. What I am suggesting would be tantamount to an ".il" file being attached to every .cs file in a project, as that is what the .cs file gets compiled to when the .dll is created.

Which is no good. :) I would argue that the .js that is created is the same. At the end of the day, when I build an application -- whether it's script or otherwise -- its final form should be transparent to me as the developer. And it is in every way in the development universe until you get to JavaScript (which obviously Script# is attempting to address).

I guess at the core here, my primary concern (and frustration) is the apparent divergence between "script-based development" and the consistency that exists with every other language in the .NET universe.

When I build an application, I don't want to worry about managing reference paths (i.e. <script> tags). When I reference another project, everything should "just work" (or resolve). Ideally, I should never, ever see JavaScript when working with my application (much like I never ever see IL).

There are a few aspects here. Source Mapping (as discussed in another thread) should address this aspect of my frustration. With source mapping, I would be seeing C# files and not JavaScript.

But really, that's just the start of what I'm pawing at.

In my mind (and I've already circled this in another thread), JavaScript "assemblies" should be one file and one file only, and that is the "assembly" of all the generated files in an class assembly poured into one file and minimized. When that assembly is referenced, that minimized .js file is what is included (automagically, just like a typical .NET assembly reference) in a dependent assembly.

I don't want to worry about managing that script reference (script tag) during the lifetime of my application.

There's a lot here. I'm just going to spend some time digging through this and see if I can create a simple Hello World application to show off what I'm thinking and the paradigm I'm pawing at. Code always speaks much louder than words. :)

[nikhilk]

Yes, go ahead and share a more concrete representation of what you're after from an experience point of view.

A few things to add that provide some context here:

It has never been the goal of script# to hide the javascript. In fact hiding it or abstracting it away would likely be an anti-feature for many. The reality is you need to interact with the source in many scenarios: debugging (as has been covered), deployment (along with other existing scripts you reference), handing generated script to someone who is going to them manually, script combining etc.

The point is script# is one tool in a large ecosystem of workflows, frameworks, tools, and host environments. The common language, or mechanism of integration, is the javascript. You can combine things at the javascript level, produce javascript, or consume/execute javascript. As such the script is quite in front of the developer stitching different things together to achieve their goals... and hiding script (for example, packaging it in the produced assembly, and written out to the response) is possible, but comes at the expense of not integrating well with the larger ecosystem.

You'll see script# tries to apply .net and c# concepts where they make sense. For example, project to project references just work, and you don't have to manually copy around scripts.

[Mike-E-angelo]

I see. Thanks for the perspective. Being a traditional Windows developer, I'd rather never ever see Script... I'd much rather work with the languages that make sense to me and have the compiled deliverables be transparent to the experience. Much like how IL is handled in the compilation process.