Console errors in browser only point to `vendor.js` - how do I find the "real" stack trace?

[woeful carbon]

Hey folks. Sorry if this is a dumb question, but I'm getting back into Ember.js after a long hiatus - long, as in, I haven't touched it since 2.13. I'm updating an old project to the current LTS version, 4.12, and one thing I'm having trouble with is running down an error that's happening in my browser's console.

The error only points to vendor.js, on a line in the tens of thousands. I thought I remember that you used to be able to make it so that when an error occurs in the console, it would instead point to the actual file in the Ember project where the error occurred, but I can't seem to find anything on Google on the subject.

We've enabled source maps in the project by editing the ember-cli-build.js file like so:

module.exports = function (defaults) {
  let app = new EmberApp(defaults, {
    sourcemaps: {enabled: true},
...

Is there more I need to do? Thanks!

[minor echo]

if you’ve built with source maps then usually if you’ve enabled them in your browser it’ll link you to the right spot, but it’ll still show the (accurate) location from within vendor for the trace

There’s sometimes exceptions where something in your build setup is changing things in a way that the source maps become invalid

usually though that still causes you to land somewhere in a source mapped file when clicking on a link in a trace, it just won’t be an accurate spot

other news: if you’ve got the trace to share, I’m happy to help you interpret it.

[woeful carbon]

Thanks @minor echo ! I can do that, one moment please

Though all of the parts of the stack trace point to vendor.js, which I don't think will be very helpful to you...but it does point out the functions in the trace, which I was able to use to locate which files the code likely passed through

Error while processing route: site.index Cannot read properties of undefined (reading 'replace') TypeError: Cannot read properties of undefined (reading 'replace')
    at Cache.func (http://localhost:4300/assets/vendor.js:27009:60)
    at Cache.get (http://localhost:4300/assets/vendor.js:11361:35)
    at decamelize (http://localhost:4300/assets/vendor.js:27063:29)
    at Cache.func (http://localhost:4300/assets/vendor.js:26987:62)
    at Cache.get (http://localhost:4300/assets/vendor.js:11361:35)
    at Object.dasherize (http://localhost:4300/assets/vendor.js:27086:35)
    at normalizeModelName$1 (http://localhost:4300/assets/vendor.js:85568:19)
    at DSModelSchemaDefinitionService.doesTypeExist (http://localhost:4300/assets/vendor.js:88697:33)
    at InstanceCache.loadData (http://localhost:4300/assets/vendor.js:88491:50)
    at http://localhost:4300/assets/vendor.js:92511:35

This actually seems to happen in the ember/string library on this line:

  var DECAMELIZE_CACHE = new _utils.Cache(1000, str => str.replace(STRING_DECAMELIZE_REGEXP, '$1_$2').toLowerCase());

Huh, moment. That seems to tell me that we're using decamelize in our project's code (and we definitely are), but for some reason it's not happy with what we're passing into it

[minor echo]

sorry I offerred to help and then got pulled off to bed

the TL;DR is this means you care calling decamelize(undefined)

specifically this is happening when normalizing some data pushed to the store (post normalization)

this means the payload being given to the store is itself invalid

by the time it hits this method, the data should be in the normalized JSON:API format

[woeful carbon]

No worries, it happens to me too 🙂

I came to the same conclusion last night, so I'm starting to trail down why the value being passed in is undefined. You still helped me reach that conclusion via rubber duck, so thank you 🙂

[minor echo]

the most likely situation is some data is either not normalized at all or is missing a wrapper

the loadData function is called for each resource in the data and included arrays (or if data is an object for that object)

e.g. store receives

{
  data: Resource | Resource[],
  included?: Resource[]
}

where Resource is a JSON:API Resource e.g.

interface Resource {
  type: string;
  id: string;
  attributes?: Record<string, JSONValue>;
  relationships?: Record<string, RelationshipDocument>
}

what this tells us is Resource is missing type

right before you hit that in the trace you'll go through the following code:

    let modelName = data.type;
    assert(
      `You must include an 'id' for ${modelName} in an object passed to 'push'`,
      data.id !== null && data.id !== undefined && data.id !== ''
    );
    assert(
      `You tried to push data with a type '${modelName}' but no model could be found with that name.`,
      this.store.getSchemaDefinitionService().doesTypeExist(modelName)
    );

    const resource = constructResource(normalizeModelName(data.type), ensureStringId(data.id), coerceId(data.lid));   

where data is the thing that is supposed to have been a Resource

if you are in a production build, then data is something that is not undefined but for which data.type is undefined

if you are in a dev build, we would see an error before this if type were undefined and you were using EmberData models unless you have a hack to make modelFor more or less always truthy (some folks added a resolver fallback to dynamically create models for instance)

so I think you are either in a prod build and just looking to see what is wrong in the payload, or in a dev build and you are looking for what sort of dastardly hack you have to make undefined still be treated as yeah, we have a model for this

hope that helps

breaking on the thrown error and walking back in the debugger should tell you what data you've received

[minor echo]

@woeful carbon did that help?

[woeful carbon]

Hey sorry, I was a bit distracted, I'll need to read through this

[woeful carbon]

Ok, finally got back to this, sorry for the delay!

Yes, what you responded with makes sense. It's funny, this worked before, but after the upgrade it's almost like the adapter requirements got more strict.

The adapter in question actually checks a local data store rather than making an HTTP request, and then formats the response to look like a JSON API response. I've updated its code to include the required keys and match the required format for JSONAPI, and the error's gone.

Thanks for your help @minor echo , I really appreciate it!

[minor echo]

Only thing odd about that is this is all internal. Even on the really old versions you are upgrading from your data needed to be json:api by then

I wonder if some other api you were using shifted on you

In the adapter/serializer or maybe a shift from pushPayload to push somewhere in your code

[woeful carbon]

That's entirely possible, though I made sure to upgrade or replace any other ember addons or node packages we were using