scriptsharp icon indicating copy to clipboard operation
scriptsharp copied to clipboard

Removing mscorlib/scriptsharp dependency on "window"

Open briantoba opened this issue 12 years ago • 1 comments

I'm building a "plugin" for a site and I've encountered some problems with sites that use ScriptSharp (older version) or sites that mess around with window.__namespaces.

The issue for me is that mscorlib assumes that the namespaces in Type.registerNamespace should hang from window. I changed this to allow me to pass to the top-level anonymous function something like window.myPlugin as the root for all the namespaces registration.

The problem comes when the normal output of ScriptSharp is like:

Type.registerNamespace('TestNamespace');

////////////////////////////////////
// TestNamespace.Class1

TestNamespace.Class1 = function() { 

TestNamespace doesn't have an explicit scope and resolves to window.TestNamespace. As this output is already wrapped in an anonymous function (to remap jQuery, for example), it'd be convenient if the output looked like:

window.Type.registerNamespace('TestNamespace');

////////////////////////////////////
// TestNamespace.Class1

window.TestNamespace.Class1 = function() { ...

And then I can remap window to the same window.myPlugin as in mscorlib and have everything separated.

This will also allow the Closure Compiler to know what's going on and really obfuscate my code.

If you can help me with a compiler that would explicitly use the window scope as in the example above, I can modify mscorlib to take a namespaceWindow or something like that. This change should have no change in behavior for any other project.

Thanks, Brian

briantoba avatar Oct 15 '12 17:10 briantoba

I'd recommend seeing the 0.8 version from the "cc" branch, or the preview build in the downloads section - the new script# produces to the module pattern, where generated script exports a module, rather than creating namespaces (which as you allude to, minimizes better), and the replacement for mscorlib.js (ss.js) also doesn't not have a global footprint when used as a module, as well as no longer depends on the "window" object.

nikhilk avatar Oct 15 '12 18:10 nikhilk