@steal and global.steal in optimize build

[pYr0x]

this PR https://github.com/stealjs/steal-tools/pull/850 adds support for @steal but whats up with the global steal, defined on the top of the optimize build here an example

/*[slim-loader-config]*/
(function(global) {
	global.steal = global.steal || {};

	global.steal.map = {
		"[email protected]#components/content/content": 141
	};
	global.steal.paths = {
		"152": "dist/bundles/steal-pwa-example/index.js",
		"153": "dist/bundles/steal-pwa-example/components/content/content.js",
		"154": "dist/bundles/steal-pwa-example/components/content/content.css"
	};
	global.steal.bundles = {
		"143": 153,
		"144": 153,
		"145": 154,
		"146": 153,
		"147": 153,
		"148": 153,
		"150": 153,
		"151": 152,
		"152": 152
	};
	global.steal.plugins = { "154": 144 };
})(window);

thats different from the @steal which seems odd

[matthewp]

It's the slim loader. The @steal module shims the one built into steal.js. the slim loader is much different as it is built or speed, not features.

[pYr0x]

i dont understand. the @loader is defined as

[
        3,
        function(stealRequire, stealExports, stealModule) {
            stealModule.exports = {
                logLevel: 3,
                meta: {},
                main: "main",
                envs: { "window-production": { serviceBaseURL: "/api/production" } },
                serviceBaseURL: "/api/production"
            };
        }
    ],

which has the config inside from e.g. the package.json or the stealconfig.js. @steal.loader is @loader.

		151,
		function(stealRequire, stealExports, stealModule) {
			var atLoader = stealRequire(3);
			var steal = {};
			steal.loader = atLoader;
			steal.done = function() {
				return Promise.resolve();
			};
			stealModule.exports = steal;
		}
	],

so what is the difference between ´@loader´ and global.steal which seems for me the same....

[m-mujica]

@pYr0x global.steal is configuration the slim loader needs to figure out where stuff is on runtime, it's not the same config you define in your package.json.

The @loader shim just exposes the properties that people tend to use, like serviceBaseURL.

[m-mujica]

e.g:

global.steal.map = {
  "[email protected]#components/content/content": 141
};

the loader uses numeric ids instead of the long module names, but for modules dynamically loaded steal-tools can't assign numeric ids since those dynamic modules are not in the graph.

The loader needs (runtime) to figure out which numeric id to use when a dynamic import is called, and that's what global.steal.map is used for.

[pYr0x]

@m-mujica thanks for clarification. maybe we can change the naming of global.steal because i think people gets confused because in normal steal, steal.System is the loader and contains mappings and serviceBaseURL too.

[matthewp]

global.steal only exists so that async scripts can add themselves to the bundle list. It's not a public API that people should use (or can use, even).

[pYr0x]

in normal steal, steal gets published to window.steal you can access steal without require it with @steal. if people do that with slim, they get back the slim loader what often is not that what you want because global.steal is the slim loader and window.steal is steal and not the loader

you understand what i mean?

[matthewp]

So I think what we need is a transform that looks for the use of the global steal and changes that to use @steal. We are doing something similar to support steal.import.

[pYr0x]

if that is possible @m-mujica ? i am ok with that...

[matthewp]

We probably will wait until there's a specific need though, most people only use steal for steal.import and that's already working.

[pYr0x]

As I said, for me it is confusing that steal is not the same on normal steal and slim-loader

I prefer to rename the config of the slim loader configs.

It is up to you if you want to change it and label that issue as enhancement