Log more helpful error for non broccoli-plugin trees & update tests

oligriffiths commented 6 years ago

We are now outputting a warning if a plugin uses the .read/.rebuild API is used: https://github.com/broccolijs/broccoli/issues/374 in ember-cli 3.4.

I took the liberty to update tests to use the broccoli-plugin API, and make this error link to the issue above, and added a test for that.

Hopefully this will aid with the transition.

Alonski commented 5 years ago

Just wondering. Doesnt this break browserify?

oligriffiths commented 5 years ago

Not sure, but that’s the point. When we cut over to Broccoli 2.0 in ember-cli it will break then in the same way. The intention here is to surface this error before then and force people to fix the issue

Alonski commented 5 years ago

Ok thanks. I guess addons using it will be too switch over to something else

oligriffiths commented 5 years ago

Yeah addons authors will just need to update to a newer version of broccoli-plugin (or update a dependency that depends on an old version)

stefanpenner commented 5 years ago

superseded by: https://github.com/ember-cli/ember-cli/pull/8083

alechirsch commented 5 years ago

I am getting this output from my build

[API] Warning: The .read and .rebuild APIs will stop working in the next Broccoli version
[API] Warning: Use broccoli-plugin instead: https://github.com/broccolijs/broccoli-plugin
[API] Warning: Plugin uses .read/.rebuild API: [object Object]
[API] Warning: Plugin uses .read/.rebuild API: [object Object]
[API] Warning: Plugin uses .read/.rebuild API: [object Object]

It looks like it might be coming from this merge. It doesn't give any information on what plugin is causing this. Does anyone know of a way to track this down and fix it?

stefanpenner commented 5 years ago

@oligriffiths thinking about this, we could offer a env variable that converts those deprecation warnings into ones will stack traces. Which may help folks.

oligriffiths commented 5 years ago

@alechirsch Please see/cross post in https://github.com/broccolijs/broccoli/issues/374

This issue is particularly difficult to debug because the point at which we know the object is invalid, we do not have a stack trace for where it was constructed (as this functionality is only part of broccoli-plugin, that the offending plugin doesn't extend). It's kind of catch 22. E.g.:

const badPlugin = {
  read() {
    // do stuff
  }
};

// pass into ember-cli-build somewhere (addon, ember-cli-build.js, etc)

Now build happens and tree is parsed and info about each node is extracted, including this validation https://github.com/broccolijs/broccoli-node-info/blob/5808e5588d3998955071c987d15436f68893bc8b/index.js#L47

So at this point, we have literally no ida where the value came from, and can't possible know.

@stefanpenner what we could do is evaluate the nodes at each stage of ember-cli building the tree, each of the treeFor methods could validate each plugin, then we could narrow it down to a specific addon, even if we don't know exactly where in the plugin the node was instantiated.

Thoughts?

ember-cli / broccoli-builder

Log more helpful error for non broccoli-plugin trees & update tests #32