subtracting a non-js dependency removes the loader plugin as well

[CxRes]

If I do something like

builder.bundle('main.js -  [settings/*.json!]', 'dist/bundle.js');

I get an error that github:systemjs/plugin-json@0.1.2 cannot be found.

However, this works:

builder.bundle('main.js -  [settings/*.json!] + json', 'dist/bundle.js');

It seems that the subtraction takes away the loader as well. This is despite the fact that several other dependencies in the tree are using plugin-json.

Using JSPM 0.16.13

[aluanhaddad]

On the one hand, this seems a bit counter-intuitive, but on the other it makes sense because any other dependencies in the tree that are loaded via plugin-json will be compiled and inlined into the bundle and therefore not have need of it.

Note that this is different in the case of a dependency that actually uses plugin-json. For example, if you add this to your main.js

import json from 'json';

it will be included in the bundle tree created by running

builder.bundle('main.js -  [settings/*.json!] + json', 'dist/bundle.js');

[CxRes]

@aluanhaddad I had tried import json in the pattern of importing other plugins and there is an error doing this. See systemjs/plugin-json#20.

[aluanhaddad]

Thanks for linking that issue.

I did not notice the problem when I tested your scenario the other day. Perhaps I messed something up when jumping back and forth between the JSPM 16 and JSPM 17 tests that I ran.

I will try to reproduce the failure to load the JSON plugin under JSPM 16/ SystemJS 19 later today.

Which, if any, transpiler plugins are you using?

I really do suggest upgrading to JSPM 17. While it is true that there are many breaking changes, the solution is usually very straightforward, and upgrading opens up many new features and workflows.

For example, I recently was able to achieve sub-second reloads in a medium size Aurelia application by using a combination of bundling and in-browser transpilation (TypeScript, Babel, SASS). I've been able to completely cut Gulp out of my toolchain which has been fantastic.

I do appreciate your request for a migration guide however I think it will be difficult to organize and compose a comprehensive guide because of the diversity of use cases in the wild and because it is not always clear, at least not to me, where documentation should live. For example, there exist bundling options that are documented on the SystemJS Builder repo but are also relevant as command line arguments to the jspm-cli. I've actually been meaning to add a bunch of cross-referencing in that area of the docs, there have been numerous issues filed against the cli repo regarding the builder, but unfortunately have not gotten around to it.

Also, depending on your usage of JSPM 16, you may require very few configuration changes. In my experience, the trickiest part has been dealing with the differences in package overrides and the changes in the JSPM Node conversion layer. Having said that, the new way it is handled is much better and easier to work with.

[CxRes]

@aluanhaddad Thanks for looking into it and the detailed reply :)

Re Config: I am using babel as my transpiler.

Re Migration: I am reluctant to migrate because I am nearly finished with my demo/experiment. I do not want to spend a week or two migrating and sorting out issues. Surely, if I start a new project or if there are plans to take this code further, I shall use 0.17.

Re Docs: I think the strategy for docs in general could do with much improvement - there is stuff at too many places and there are inconsistencies as a result. One idea could be to have a separate repository that contains doc for the entire jspm toolchain (cross referencing can get quite flaky). The challenge is ensuring downstream libraries are documented consistently with the versions used in the particular jspm release. The same thing is happening with issue-management, people are filing issues in multiple places.

A migration guide imho will do wonders for adoption. Do it only for a non-trivial vanilla js or perhaps with nodejs, nothing more - no task runner, no front-end frameworks etc. This should not be that difficult since as regular user, you would have faced 80% of issues that a random user would face and saves them all the heartache (As I pointed somewhere else, this is like asking for a free lunch). Another thing that is unclear is determine where jspm is at - What are the plans for the future, what timelines one could expect etc.

[aluanhaddad]

Re Docs: I think the strategy for docs in general could do with much improvement - there is stuff at too many places and there are inconsistencies as a result. One idea could be to have a separate repository that contains doc for the entire jspm toolchain (cross referencing can get quite flaky).

While I like the idea of having a separate repository for documentation, the issue I see with it is the distinction between JSPM and the larger ecosystem of SystemJS and its plugins. Ironically, this fuzziness is manifest in this very discussion as this issue could easily have been opened on the JSPM repo and been equally relevant :). Also, when I spoke of cross referencing, I was actually thinking of cross referencing between JSPM and the various SystemJS repositories.

The challenge is ensuring downstream libraries are documented consistently with the versions used in the particular jspm release. The same thing is happening with issue-management, people are filing issues in multiple places.

JSPM is actually fairly cohesive and I think it is fine for the documentation to reside alongside the CLI since the other repositories, such as the registry, do not exhibit as much issue leakage.

Of course, this leads all leads directly to your next remark.

Another thing that is unclear is determine where jspm is at

(please note that these are just personal thoughts)
It depends on how you look at it . SystemJS on its own is a great tool but for me, JSPM is essential to the productive and pleasant use a tool that otherwise requires substantial manual configuration. I think Guy Bedford's motivation for JSPM, which was at least in part the need for loader aware package management and the need to automate the complex task of writing, maintaining, and sharing RequireJS style configuration, still rings as true today as it did back in 2014 when he gave this talk.

I realize this doesn't answer your question.

[CxRes]

I realize this doesn't answer your question.

:)