These are chat archives for systemjs/systemjs

17th
Jul 2017
Randall Leeds
@tilgovi
Jul 17 2017 00:02
@wmhilton I've been looking for something like this for about a month now. I spent some time making a plugin myself. I also spent time trying pre-building the config based on npm5 package-lock.json. I got quite far, but supporting fallback to .json and /index.js when module names don't end in an extension is a lot of noise. Without pre-parsing all the files and following their requires/imports/etc it doesn't seem like there's a great way forward.
My only other idea that I might explore is to do this for a dev server with the expectation that the future comes with script type=module support and full es6 modules. My idea is a dev server that provides a websocket endpoint and a System.resolve hook that uses the websocket for RPC to resolve from node.
<shrug>
Otherwise, I think I might either use JSPM or retreat.
Med Douici
@400k
Jul 17 2017 07:15
@Izzmo I am using the transpiler in-browser but I expect normally that those whatever.ts should be compiled to whatever.js to avoid the XML Parsing Error, as I am following the SystemJS module how it works, it change the files to the ES5 way and give back the TS file with the TS extension and not with the JS extension. I have tried this in Chrome and no error have appeared
Nick George
@Izzmo
Jul 17 2017 13:08
@400k yep, that should work. I haven't seen the "XML.." bit though. Are you trying to load up an xml file or some sort?
William Hilton
@wmhilton
Jul 17 2017 13:41
@tilgovi Sounds like we're on the same wavelength. Admittedly, a lot of npm modules simply won't work in the browser. But a lot of them would. And admittedly, some will only work if the exact versions of the dependencies declared in package.json are used, rather than simply using the latest version. But a lot of them would. And some are going to be dependent on Node's internal module cache architecture and side effects and not work with shims for the builtins. But that's the exception. A LOT of them though are going to rely on package.json's "module", "browser", or "main" property, the default "index.js" assumption, and the directory ascending algorithm. That's a major hurdle, but one that can be overcome with lots of calls to window.fetch. Once resolved though we can cache the results so it's faster on the next page reload.
William Hilton
@wmhilton
Jul 17 2017 13:49
@tilgovi OH. Here's another idea. What if instead of trying to load modules from the web, we downloaded them to a virtual filesystem like browser-fs and got jspm to run in the browser?
William Hilton
@wmhilton
Jul 17 2017 14:03
@tilgovi we should just reverse engineer requirebin
@tilgovi I didn't realize it was entirely client side: http://requirebin.com
Randall Leeds
@tilgovi
Jul 17 2017 17:22
@wmhilton we know from the experiences of browserify and webpack that using module/browser/main and bundling works fine for loads of things on npm.
With npm5, the package-lock.json is a frozen map to where modules are installed.
What I've found to be the real difficulty is that require('foo') (or import ... from 'foo') can be foo.js, foo.json, foo/index.js, foo/index.json.
There's no way to do that from within SystemJS in the browser without having failures and fallback and it doesn't really fit neatly into the plugin hooks for locate and fetch. The only way to know ahead of time would be to crawl all the dependencies, like a bundler does, and try to figure out up front what all is required by what.
What I really want is a way to not know that, not crawl that, not be regex'ing or parsing modules to statically figure out all the resolutions.