These are chat archives for systemjs/systemjs

20th
May 2016
Ben Sandwick
@ben657
May 20 2016 08:37
@guybedford for yesterday, the templates file was an es6 module, but i've just got it imported in the crDash file, makes more sense like that anyway in retrospect
Scott Nicolson
@scottnicolson
May 20 2016 09:14
@guybedford Babel 6 isn't supported in the current version of jspm. i am trying to update to jspm@beta but i don't think this will fly as we will be using it in production.
JavaScriptNinja
@born2net
May 20 2016 15:31
anyone has an idea how to remove Error:(4, 20) TS2307: Cannot find module 'underscore'.
I am using systemjs and trying to remove my require statements to all imports
all works fine in runtime using: import * as _ from 'underscore'
but still I get the annoying TypeScript error...
I also mapped already in config.js and even installed its typings via: typings install underscore --ambient --save
tx
Joel Denning
@joeldenning
May 20 2016 17:18
@guybedford question for you: I am running tests in node on my SystemJS project, but want to mock the window. That might sound contradictory, but let me explain: I’m in a node environment but the code that is being tested references the window. If I try to mock the window with global.window = { addEventListener: function() {} }, I get errors inside of plugin-babel because now plugin-babel thinks it’s running in a browser environment.
Do I have any hope for being able to pull that off? See CanopyTax/node-jspm-jasmine#29 for more details
Guy Bedford
@guybedford
May 20 2016 17:20
@joeldenning adding a global like that in Node is not advisable at all
if possible use require('vm').runInContext or something like that to run the code in a sandbox
there's also the metadata.globals option for loading global modules in SystemJS
Joel Denning
@joeldenning
May 20 2016 17:27
Hmm.
Not sure if require(‘vm’).runInContext could work, since I’m just System.importing the file and I wouldn’t want SystemJS to run in the same sandbox
Is there docs for metadata.globals? I’ll maybe read into that
Guy Bedford
@guybedford
May 20 2016 17:32
it works for commonjs and global modules
Joel Denning
@joeldenning
May 20 2016 17:43
This might be a stretch, but any way to configure the meta.globals at runtime?
Guy Bedford
@guybedford
May 20 2016 17:43
If you know the module name, you can set the metadata just before importing
Joel Denning
@joeldenning
May 20 2016 17:44
System.meta[key].globals ={ window: ‘path-to-my-window-object’ }?
Guy Bedford
@guybedford
May 20 2016 17:44
yes exactly
although best to use a System.config call always
Joel Denning
@joeldenning
May 20 2016 17:44
Oh okay
what’s the difference?
Maybe that with System.config()I don’t have to know the normalized name?
Because it appears that the properties in System.meta are normalized names
Guy Bedford
@guybedford
May 20 2016 17:48
yeah, and you also get validations for other configs, so it's the best habit always for config
there is discussion to remove the base-level properties in 0.20 for a System.getConfig rather
Joel Denning
@joeldenning
May 20 2016 17:50
By base-level properties you mean being able to access the config directly via property lookup System.meta?
Guy Bedford
@guybedford
May 20 2016 17:51
yeah, it will also allow us to batch the config normalization, reducing the chance of ordering issues too
tracking in systemjs/systemjs#999
Joel Denning
@joeldenning
May 20 2016 17:57
awesome, seems like meta.globals will completely solve this problem. Will be a very useful feature for node-jspm-jasmine