typescript not found about plugin-typescript HOT 13 CLOSED

Actually I do have typescript installed as a global too, and am still getting this.

The actual error is GET file:///Users/guybedford/Projects/jspm-cli/sandbox/typescript/bin/lib.d.ts net::ERR_FILE_NOT_FOUND.

from plugin-typescript.

This is because when compiling it needs to fetch this declaration file which is shipped with the typescript compiler. I need to make a change so that it resolves it correctly, but until then you have to add an explicit mapping to the file - see #6

My mapping looks like this:

"typescript/bin/*.d.ts": "jspm_packages/npm/[email protected]/bin/*.d.ts",

from plugin-typescript.

You can call:

System.normalize('typescript', __moduleName)
.then(function(normalized){
  return System.locate({ name: normalized, metadata: {} });
}).then(function(pathToTypeScript) {
});

to access these paths through the loader API.

from plugin-typescript.

thanks, that's now fixed in 0.5.7.

from plugin-typescript.

Actually there is still an issue here - if the root project does not have typescript installed then the resolution fails.

It seems to be because __moduleName is set to http://localhost:8081/jspm_packages/github/frankwallis/[email protected]/lib/format-errors.js which is actually the module address. I've traced it through to here:

// Define our eval outside of the scope of any other reference defined in this
// file to avoid adding those references to the evaluation scope.
function __eval(__source, __global, load) {
  // Hijack System.register to set declare function
  var __curRegister = System.register;
  System.register = function(name, deps, declare) {
    if (typeof name != 'string') {
      declare = deps;
      deps = name;
    }
    // store the registered declaration as load.declare
    // store the deps as load.deps
    load.declare = declare;
    load.depsList = deps;
  }
  try {
    eval('(function() { var __moduleName = "' + (load.name || '').replace('"', '\"') + '"; ' + __source + ' \n }).call(__global);');
  }
  catch(e) {
    if (e.name == 'SyntaxError' || e.name == 'TypeError')
      e.message = 'Evaluating ' + (load.name || load.address) + '\n\t' + e.message;
    throw e;
  }

when it does the eval, load.name is correctly set to github:frankwallis/[email protected], but __source is set to this:

"var __moduleAddress = "http://localhost:8081/jspm_packages/github/frankwallis/[email protected]/lib/format-errors.js";System.register("http://localhost:8081/jspm_packages/github/frankwallis/[email protected]/lib/format-errors.js", ["typescript"], function($__export) {
  "use strict";
  var __moduleName = "http://localhost:8081/jspm_packages/github/frankwallis/[email protected]/lib/format-errors.js";
  var ts;
  function formatErrors(diags, logger) {
    /* MORE CODE */

so the good value of __moduleName gets overwritten by a bad value - coming from traceur by the look of it.

@guybedford - have you seen this before? Traceur is adding its own __moduleName variable to the transpiled source, and setting it to the module address.

from plugin-typescript.

@frankwallis thanks I've created ModuleLoader/es-module-loader#332.

from plugin-typescript.

@frankwallis what version of Traceur are you using here? We've definitely got this in the tests, so I'm not sure why it's failing for you (System.traceurOptions.moduleName = false should make sure Traceur doesn't set this).

from plugin-typescript.

@frankwallis is this specifically for builds?

from plugin-typescript.

@guybedford - I'll have to get back to you later about this - what do you mean by 'specifically for builds'?

from plugin-typescript.

Sure thanks, no rush. I meant as in if the error came up while running builds or in the browser. Because the in-browser case is very much tested - https://github.com/ModuleLoader/es6-module-loader/blob/master/test/loader/moduleName.js, also why I suggested ensuring Traceur is up to date.

from plugin-typescript.

It is happening in the browser, when compiling the plugin-typescript example project. What I am seeing is that with traceur 0.0.84 (default version from jspm) it fails as described above (even if I set moduleName: false), but when I manually update traceur to 0.0.87 then everything works as expected.

from plugin-typescript.

@frankwallis ok thanks. It sounds like this is due to that previous Traceur regression then, which should fix up in the next update.

from plugin-typescript.

this was resolved in jspm 0.15

from plugin-typescript.