These are chat archives for systemjs/systemjs

22nd
Jul 2015
Jordan Weitz
@newduke
Jul 22 2015 00:59
afaict, relative identifiers work in systemjs, after testing just that behavior... but the ones in the minified ace loader do not.
Peter Müller
@Munter
Jul 22 2015 07:55
@newduke This might just be a case of ace needing some overrides because the internals maybe aren't compatible with standard module loader syntax out of the box. Might just be a format that need to be set. What setup do I need to recreate the error you are seeing?
Peter Müller
@Munter
Jul 22 2015 12:43
@guybedford Does systemjs add any custom headers to fetch calls to indicate that this request is done by systemjs? Or does it set referrers or anything similar? When writing static file express middlewares it's probably important to know when to intercept and when not to
Guy Bedford
@guybedford
Jul 22 2015 12:50
@Munter yes it's a great point. Can't add custom headers due to CORS unfortunately so would need to be a safe header
I've actually been pushing for whatwg/loader#29 at the spec level here
Peter Müller
@Munter
Jul 22 2015 12:52
The alternatives I can think of is having the intercepting middleware alter the baseURL and intercept anything going to the alternate path
But then I'd need a guarantee that baseURL is set in config.js so I can tak over control of it
Appending a GET parameter might also be used to indicate origin
but that's something I have less control over in the pipeline
Guy Bedford
@guybedford
Jul 22 2015 12:53
I do like the idea of having paths configurations for the server which are "module paths"
at the server-config level
it could potentially upgrade in jspm environments to read config.js
I guess the question is how to do sourceURLs etc with this
header would be ideal
Peter Müller
@Munter
Jul 22 2015 12:54
I would need to rewrite those as well in reverse
Guy Bedford
@guybedford
Jul 22 2015 12:54
do source map requests have a special header?
I really like the idea of the moduel loader always sending an accept header though
it just seems to make so much sense
accept: script/module
Peter Müller
@Munter
Jul 22 2015 12:55
A header would only work if you tell plugin authors to use System.fetch instead of window.fetch. Only way to guarantee that you only add headers when System is involved
Guy Bedford
@guybedford
Jul 22 2015 12:55
the default browser loader comes with its own fetch implementation
trying to get it in that
Peter Müller
@Munter
Jul 22 2015 12:55
ah, accept header is certainly a good one to set
Guy Bedford
@guybedford
Jul 22 2015 12:56
but needs spec backing
Peter Müller
@Munter
Jul 22 2015 12:56
accept: script/module */*
Guy Bedford
@guybedford
Jul 22 2015 12:56
can't just do something without consent
unless we prefix
accept: script/x-module-loader-module
Peter Müller
@Munter
Jul 22 2015 12:56
prefix is fine for anyone on the server side as well
Guy Bedford
@guybedford
Jul 22 2015 12:57
lets do that actually
Peter Müller
@Munter
Jul 22 2015 12:57
accept content types is just a list of alternatives to try. So as long as a */* is also in there then it should be backwards compatible is there is no middleware intercept
Guy Bedford
@guybedford
Jul 22 2015 12:57
awesome
feel free to add script/x-module-loader-module as an accept header to https://github.com/ModuleLoader/es6-module-loader/blob/master/src/system-fetch.js#L38
Peter Müller
@Munter
Jul 22 2015 12:58
Would still require plugin authors to use System.fetch, which overloads the accept header
Guy Bedford
@guybedford
Jul 22 2015 12:59
yes
the third argument to the fetch plugin hook is the default fetch implementation
maybe it should be module/x-module-loader-module?
Peter Müller
@Munter
Jul 22 2015 13:01
There is one more piece of information I might need on the server end. If the file is supposed to be translated by a plugin in the module description. In that case I need to have that in the expression I pass to system.builder on my end. Otherwise the middleware will miss all of those and create errors
config.js shim defined loaders should pick up fine
Guy Bedford
@guybedford
Jul 22 2015 13:02
so you support config.js?
Peter Müller
@Munter
Jul 22 2015 13:02
I read it in based on package.json, then builder.loadConfig
That works
I'll add options to pass in specific paths later
Still piecing things together
Guy Bedford
@guybedford
Jul 22 2015 13:04
cool
Peter Müller
@Munter
Jul 22 2015 13:04
Another idea I had was to use traces of built files, read the deps, amend config.js with those deps, which should enable the browser to trigger downloads earlier and in parallel
Might not make much difference on http1. But http2 I think it would be considerable
Guy Bedford
@guybedford
Jul 22 2015 13:05
You mean like jspm depcache?
Peter Müller
@Munter
Jul 22 2015 13:05
yes. So basically the longer the server runs, the faster reloads become
Since I know the url of config.json I can just intercept requests to it and change or amend configuration to aid the middleware
Guy Bedford
@guybedford
Jul 22 2015 13:08
awesome
yeah the analysis can do a lot there
I would suggest not handling plugins loaded via plugin!
I really want to deprecate these types of plugins, and only use this for "production plugins" if anything
Peter Müller
@Munter
Jul 22 2015 13:09
Another potential to reduce requests could be to inline the dependencies as system.register in the response if they are already in the middleware cache
Guy Bedford
@guybedford
Jul 22 2015 13:09
plugins via configuration is really the way to go
Peter Müller
@Munter
Jul 22 2015 13:09
But I'm getting way ahead of myself :)
Guy Bedford
@guybedford
Jul 22 2015 13:10
hehe, have so many ideas on this stuff too
Peter Müller
@Munter
Jul 22 2015 13:10
This is one of the reasons I like this project a lot. I think these are the right abstractions that we will not have to undo when browser development catches up
The rest is just building the toolset to regain the speed that the broken task runner setups provide
Guy Bedford
@guybedford
Jul 22 2015 13:11
yes exactly
the goal is also to put pressure on the specification process itself
so we can get the native benefits sooner as well
can be frustrating though when most of the spec authors haven't used the project
Peter Müller
@Munter
Jul 22 2015 13:13
What will it take to make them more receptable to trying it?
Guy Bedford
@guybedford
Jul 22 2015 13:13
popularity
Peter Müller
@Munter
Jul 22 2015 13:14
I'll do what I can from my side. If the tool integrations are there I hope people will see it as a viable alternative without sacrificing benefits they had on gulp/broccoli/webpack
Guy Bedford
@guybedford
Jul 22 2015 13:15
thanks, yeah that would be ideal
Paul Jolly
@myitcv
Jul 22 2015 13:25
Hey all. I'm seeing a problem with "Uncaught not found" errors. I get messages of the kind: Error loading "A" from "B". But "A", in this instance, is transitively loaded via "C" (which is loaded by "B"). So whilst technically correct, the error message is not particularly helpful because I have to go searching for where in the chain things broke. Is this a known issue, or something specific to my setup? Thanks
Guy Bedford
@guybedford
Jul 22 2015 13:56
@myitcv this is actually being worked on in ModuleLoader/es6-module-loader#404
Paul Jolly
@myitcv
Jul 22 2015 14:00
@guybedford - thanks
Nick
@NicholasGW
Jul 22 2015 19:02
I'm having a touch of trouble regarding babel now as well. If I specify babel as my transpiler, and then download it via jspm, should I be able to load React components that use JSX and ES5 syntax?
I seem to be getting unexpected token "<" as if it's not translating the JSX
Guy Bedford
@guybedford
Jul 22 2015 19:19
Babel support is only included for modules that are detected as ES6 modules
otherwise you need to use a plugin
Nick
@NicholasGW
Jul 22 2015 19:20
ahhhhh okay that makes sense now, I kind of figured that might be the case. I was using the jsx plugin but now that it is being deprecated I was hoping to switch to babel
jsx plugin still the best bet for the time being?
Guy Bedford
@guybedford
Jul 22 2015 19:20
yes if it isn't an es6 module you always need to use a plugin
Nick
@NicholasGW
Jul 22 2015 19:21
excellent, thanks a lot!
Guy Bedford
@guybedford
Jul 22 2015 19:21
we're looking at separating the module format from the transpiling though
Nick
@NicholasGW
Jul 22 2015 19:21
oh excellent. that would be helpful indeed
it would be nice just to set babel and not need to think about ES5/React/JSX/ES6 etc
or rather, using different things for each
thanks a lot, really love both these projects and push them hard on everyone I meet, so it's much appreciated :)
Guy Bedford
@guybedford
Jul 22 2015 19:22
thanks, glad to hear that!
If you're interested you can follow the discussion on this topic in systemjs/systemjs#579
Nick
@NicholasGW
Jul 22 2015 19:23
ah perfect! Will do
Martin Segado
@msegado
Jul 22 2015 22:00
Hey folks - I'm starting to think about my production builds and was wondering: does anyone have thoughts on doing dead-code elimination across modules in a bundle...?
seems like it would be nice to be able to import a module, use only one function or variable from it, and have the rest removed by some form of DCE
Peter Müller
@Munter
Jul 22 2015 22:24
@msegado the dependency graph has enough information in it to run static analysis tools to do this. But you would have to implement it on to of the eco system. At least I don't know of anyone who has done it yet
Martin Segado
@msegado
Jul 22 2015 22:55
@Munter Cool, thanks for the tip. Not sure I'm going to jump in on it just yet, but it would be an interesting project.