angular-cli: Importing adhoc 3rd party lib fail

@SergeySolonko Clearly, that wiki page didn’t help one bit. Was the first thing I read. Wouldn’t be writing a comment here, otherwise.

For the record, after hours of pointlessly staring at my screen in bewilderment, I managed to make ng2-charts work. Here’s a summary of what I did:

Configure URLs and packages

Edit system-config.ts and have it declare ng2-charts and all its dependencies. Manually. The only way of knowing which dependencies are those, AFAIK, is running your application and keep track of all 404 you’ll get. Or dig out each package.json for a list. Once you do that, repeat the step for the dependencies of the dependencies.

After some trial and error, I figured out ng2-charts depends on color-name, color-convert and chart.js. In turn, chart.js depends on chartjs-color, chartjs-color-string and moment.

So, you need to follow all steps on the wiki guide for each one of those.

Also, bear in mind that deps may be bundled or distributed differently. So when configuring them, you need to specify their correct format.

In the end, my system-config.ts looked like this:

/***********************************************************************************************
 * User Configuration.
 **********************************************************************************************/
/** Map relative paths to URLs. */
const map: any = {
  'ng2-charts': 'vendor/ng2-charts',
  'chartjs': 'vendor/chart.js/dist/Chart.bundle.min.js',
  'color-name': 'vendor/color-name/index.js',
  'color-convert': 'vendor/color-convert/index.js',
  'chartjs-color': 'vendor/chartjs-color/dist/color.js',
  'chartjs-color-string': 'vendor/chartjs-color-string/color-string.js',
  'moment': 'vendor/moment/moment.js'
};

/** User packages configuration. */
const packages: any = {
  'ng2-charts': { defaultExtension: 'js', main: 'ng2-charts.js' },
  'chartjs': { defaultExtension: 'js', format: 'cjs' }
};

Update your CLI build

Add the following to the angular-cli-build.js file on the vendorNpmFiles array:

      'color-name/**/*.+(js|js.map)',
      'color-convert/**/*.+(js|js.map)',
      'chart.js/dist/Chart.bundle.min.js',
      'chartjs-color/dist/color.js',
      'chartjs-color-string/color-string.js',
      'ng2-charts/**/*.+(js|js.map)',
      'moment/moment.js'

Manually import charts.js

You need to import 'chartjs'; somewhere in your application to make System.js load Chart.js. I did that on my root component. Otherwise, ng2-chart will just fail silently.

So, all in all, the state of the art looks very bleak presently. At least for me. Unless I’m missing something important or doing something terribly wrong, this is right-down unusable. Whatever we are doing to Javascript needs to stop. Now.

(Ok, that was a joke… but really, this is very cumbersome).

@nfantone Holy smokes dude, saved me a ton! Thanks for the beautiful walk through the systemJS config and the cli-build! You came in clutch with that! Thank You!

I am loathe to mention any other big tools, but this whole category of problem is approximately what JSPM solves. There is some chance that by iteratively solving this problem again here, this project will reinvent JSPM.

Indeed. I should have said, aims to solve. Though I don’t think it deserves anywhere near as much negative comment as it gets. Particularly because, as far as I know, no other tool has stood up to do the same things better. But relevant to this item, I think to achieve a level of automation JSPM aspires to (and to a considerable extent delivers), CLI may end up needing mechanisms analogous to most of the mechanisms in JSPM. I don’t know how deeply this will go; possibly by setting aside the notion of consuming non-NPM packaging, the result can be less work than JSPM has been. Hopefully, because JSPM has been under development for a long time, and the Angular community could benefit from a fairly complete CLI in a short time.

About your question of why, I agree wholeheartedly. However, this is the sort of problem that seems exasperating from afar and is exasperating in a totally different way from near. For example, why couldn’t we just stick with the old CommonJS module format? The answer is, because it just does not work for various things that are pretty important today.

@nfanton yea, good call. I’ve just been battling this for long enough that I forgot the purpose of registering the lib with system.js.