fix(shim-commonjs): fix to stop format being hard-set to 'global' when a...

[frankwallis]

... shim is present

So according to the spec, shims are not limited to globals, but in fact specifying a shim for a commonjs module sets the format to global in the meta, which causes 'require is not defined' errors. This change only sets the format to global if the shim has exports defined.

There are also a couple of other potential issues which I have added tests for but not fixed as I would like to know what you think first:

1. When compiling a directory it globs every single js file in the directory, normally this is not important but when doing jspm link it means that it is traversing the whole of node_modules and jspm_packages which is rather slow. If the module has directories.lib set then it avoids the problem but that is not always possible.

2. Because of the globbing, it is not possible to shim files unless they have a '.js' extension. I think that the shimmed filenames (ie the keys of 'shim') should be included in the glob. In my case I would like to shim a typescript file (.ts) with some css.

[lookfirst]

According to travis, it appears you forgot to add ignoreme.js to git

[frankwallis]

oh yes, my fixture file got gitignored. updated, thanks.

[lookfirst]

👍 for tests!

[guybedford]

Unfortunately this change isn't backwards compatible, so won't work in its current form.

The plan is very much to support this though, by providing a "v2" package syntax in jspm and run this update in one go.

The new package config will look like:

{
  "modules": {
    "some/module.js": {
      "format": "global"
    },
    "lib/*": {
      "format": "es6",
      "plugin": "jsx",
      "deps": ["react"]
    }
  }
}

For example. Any help reaching this point though would be incredibly welcome. I'm going to be starting to put together the roadmap and issue steps to reach this milestone.

For the other points:

1. This is a known issue, and the suggested fix is apply lib, files and ignore before endpoint build #345. Let me know if you have any more questions on that there.
2. As you can see, the new syntax above does not rely on file extension assumptions.

[frankwallis]

I see, well that's ok I can just require the css in the javascript for now.

I would really like to help out - so I guess just ping me when you have put together the roadmap and you can assign me some tasks if you want. Is there anywhere to discuss the package config changes currently or will that be on the roadmap?

[guybedford]

@frankwallis thanks for expressing an interest in contributions. Getting the TypeScript stuff working well would be an amazing focus, especially with regards to the new System.register output they've been working on. If you ever want to discuss this at all please let me know. I've also updated the contributors' guide at https://github.com/jspm/jspm-cli/wiki/Contributors%27-Guide.

[frankwallis]

@guybedford yes, I have been thinking about that, and it is something I could take on over the next week or two. So yes, 'assign' this to me and I will make a start.

I have created an issue on plugin-typescript frankwallis/plugin-typescript#16 to discuss the changes. Interested to know your thoughts on that. If you also are able to quickly list the places where you know changes need to be made that would be helpful, so far I can think of:

• systemjs - doing the transpilation
• jspm-cli - configuration options and compiler installation

[frankwallis]

@guybedford - I may have got the wrong end of the stick here - are you imagining that TypeScript would become an integrated transpiler option like Babel/Traceur, or do you think it should remain as a separate plugin?