sglanzer-deprecated/ember-cli-blanket

Uncaught Error: Could not find module...

Closed this issue · 8 comments

I attempted to use this add on against an installation of https://github.com/softlayer/sl-ember-translate. Without its use the tests at :4200/tests run just fine, but with this add on this is displayed in the browser:

global failure (1, 0, 1)
Uncaught Error: Could not find module sl-ember-translate/index
Source:
/assets/vendor.js:65

and this In the console:

Uncaught Error: Could not find module sl-ember-translate/index loader.js:58
requireModule loader.js:58
reify loader.js:41
requireModule loader.js:69
oldLoader blanket-loader.js:31
_blanket.extend.utils.processFile blanket.js:5241
blanketLoader blanket-loader.js:24
(anonymous function) blanket-loader.js:45

I started digging around into these errors but I'm hoping that they make more immediate sense to you and you can provide some guidance.

Does sl-ember-translate use a custom module loader? That would be my first guess. I'd also take a look at/debug the loading of that module in the blanket-loader.js, there may be dependencies that need to be ordered, as the loader currently loads all modules in the application from top to bottom.

I get the same error when trying to use https://github.com/RSSchermer/ember-spectrum-color-picker, for what it's worth; that one is trivial, it's (basically) a single file that wraps an existing JS library, so there's no custom loader there.
It'll happen in an otherwise completely empty project -- repro steps:

  1. ember init testcoverage
  2. cd testcoverage
  3. npm install ember-spectrum-color-picker --save-dev
  4. ember generate ember-spectrum-color-picker
  5. ember serve, then go to localhost:4200/tests, everything is fine.
  6. stop ember serve
  7. npm install ember-cli-blanket --save-dev
  8. ember generate ember-cli-blanket
  9. ember serve -- go to localhost:4200/tests, now we get
    Uncaught Error: Could not find module ember-spectrum-color-picker/index
    Source:
    http://localhost:4200/assets/vendor.js:65

For what it's worth, a workaround in this particular case is to add:
loaderExclusions: ["spectrum-color-picker"]
to blanket-options.js.

I'm still not sure what makes the loader so unhappy -- the spectrum-color-picker wrapper is very tiny so there's something pretty fundamental here.

For what it's worth, my guess is that the loader gets confused because spectrum-color-picker has, in addon/components/spectrum-color-picker.js:
import Ember from 'ember';

export default Ember.Component.extend({
classNames: 'spectrum-color-picker',
tagName: 'input',
... then the rest of the wrapper ...
});

and in app/components/spectrum-color-picker.js:

import SpectrumColorPickerComponent from 'ember-spectrum-color-picker/components/spectrum-color-picker';
export default SpectrumColorPickerComponent;

and something in the loader is getting confused because there's two files with the same name and it's lost track of which file it's trying to load.

Looking at the first post in this thread, sl-ember-translate has the same structure (addon/components/sl-translate.js and app/components/sl-translate.js with the same sorts of things inside them, so I suspect this problem will arise with any other addon that uses this structure.

Thanks for the additional details - I'll create a test project with the spectrum-color-picker and attempt to resolve this. We have a number of addons in our project, but it's possible that none use that structure.

I get the same error too for the following modules

ember-cli-bootstrap
ember-cli-datepicker
ember-cli-jquery-ui
ember-idx-forms

this can be reproduced by a blank app after installing the above modules and run its generator

@hwwan80 @notmessenger Looking into this now. The scope of the code coverage may need to be scaled back to handle these situations. Currently every module is run through the instrumentation so that a full picture of the project's code coverage is displayed. I need to find a way to exclude addons from the instrumentation since the code coverage for those should be done in their own projects, not in the projects that use the addons.

@hwwan80 @notmessenger I believe I've resolved the first portion of this issue. The blanket-loader will now avoid instrumentation of any modules that don't contain the project's modulePrefix. I've confirmed this against ember-spectrum-color-picker and sl-ember-translate.

Unfortunately, I haven't determined a way to distinguish between modules in the app directory that originated from an addon versus those actually present in the app directory, so the addon modules are still part of the coverage report. At least the coverage doesn't break at this point though.

This is available in 0.2.4.

Closing in favor of #17