Doesnt work with jspm 0.17.0-beta.22

[el-davo]

Hi. I just updated my angular2 project from jspm version 0.16.39 to 0.17.0-beta.22

After updating whenever i try and import a html partial it comes out as "undefined". I am using the meta tag like so

packages: {
    "app": {
      "defaultExtension": "ts",
      "meta": {
        "*.html": {
          "loader": "text"
        }
      }
    },
    "base/app": {
      "defaultExtension": "ts"
    }
  }

And importing like so

import template from './main.html';

Any help appreciated

[guybedford]

Which version of the text plugin are you using here? Make sure you're running the latest 0.0.8.

[el-davo]

Hi. I have 0.0.8 installed

"text": "github:systemjs/plugin-text@^0.0.8",

Ill try and do some more debugging to see whats up

[el-davo]

So i managed to figure this out. After the upgrade something put this in my jspm.config.js file

typescriptOptions: {
    "module": "commonjs",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true
  },

Removing the module line seems to work so it should look like this

typescriptOptions: {
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true
  },

Maybe someone can shed some better light on the significance of that parameter?

Feel free to close this issue

[aluanhaddad]

@guybedford I believe the issue stems from the following change f6ba200

I'm not entirely sure I understand the reason for the change, but the effect is that importing text via default import syntax only works when either

1. setting "module": "system", via tsconfig.json or typescriptOptions
2. using bundling, e.g jspm bundle app --inject

I tried with both [email protected] and 2.0.0, and with the latest dev build via both [email protected] and 4.0.16. I also tested via the command line compiler. TypeScript always attempts to access the export named default, but the text plugin generates an anonymous define unless builder is defined. I think plugin-typescript may have some magic to make this work, but I'm not sure.
/cc @frankwallis

Personally, I didn't run into this issue because I was always transpiling with "module": "system".

I think this is a pretty serious issue. It is very surprising because there are several implicit behaviors at work in TypeScript, in plugin-text, and plugin-typescript which interact oddly.

It may be worth mentioning that I am currently working on a project which uses Webpack (not my choice or preference) and TypeScript. In Webpack, the import template from './app.html'; syntax doesn't work at all. The result is always undefined. Thusly all templates must be imported via require, which is annoying.

@el-davo
The module parameter passed to the plugin-typescript and through that to TypeScript specifies the module format compilation target. It appears that "module" is being automatically set to "system" somewhere when left unspecified. However the default module format used by TypeScript is "commonjs", so it behaves very differently. Regardless, not specifying this option is a very bad idea. You should specify "module": "system" for the time being because you are producing register output, not cjs, so do not be mislead by the absence of the explicit "module" parameter.

[guybedford]

I can't seem to replicate this here at all.

Here's the steps I took:

Running jspm 0.17-beta.22 and plugin-typescript 5.0.8 against Typescript 2.0.0.

System.config({
  meta: { '*.txt': { loader: 'text' } }
});

test.js

import text from 'file.txt';
console.log(text);

with a System.import('test.js') works completely fine for me.

What can I do to replicate this further?

[frankwallis]

Perhaps try setting allowSyntheticDefaultImports: true in tsconfig/typescriptOptions? This is defaulted in the latest version of plugin-typescript, but if you are using an older version then it won't be.

[crystalbyte]

I do observe the same issue, I use [email protected] and [email protected].
In my case, however, I do not use typescript with systemjs at all.

[aluanhaddad]

@crystalbyte If the JavaScript that executes references the default property of the imported module which plugin-text generates you will experience this issue because the plug-in is not generating an export with that name. I don't think this is a TypeScript related issue at all.

[crystalbyte]

@aluanhaddad Thanks, I will check that and get back to you.

[guybedford]

This project exports as export default text. Whatever is used to load the text content is responsible for doing import text from 'text' and picking the default export. Marking this as a duplicate of #34.

[guybedford]

(note that the AMD form returned when builder is not defined, means returning the default, as AMD and CommonJS modules ARE the default export for interop. If not, the interop system is not working correctly)

[aluanhaddad]

@guybedford #34 is unrelated. Specifically, the issue there was TypeScript providing a static error because the typechecker did not understand that the HTML imports were consumed as synthetic modules created by the plugin at runtime. That issue was purely a static type checking issue and did not affect runtime behavior in any way, it was just annoying because you had to use a workaround to silence the type checker (fixed in TS 2.0).

I think that, as you say, there must be something wrong with the interop which translates the resulting AMD module endowing it with a default property. The code generated by the typescript compiler for

import template from './template.html';

accesses the default property of the module namespace object and has not changed for at least 9 months.
It is

var template = template_1.default;

Sorry for being long-winded, but I just wanted to clarify that #34 is completely unrelated.