The "path" argument must be of type string.

[herman-rogers]

Basically just installing it and running ember s I get the error The "path" argument must be of type string. Received type undefined. So I'm assuming there's an issue with importing some path. Don't have time to investigate it now but thought I'd throw it up here.

Here's the project if you want to test it out: https://github.com/herman-rogers/ember-osf-web.

[jderr-mx]

I am receiving this error as well.

Here is what I think is the relevant bit from the stacktrace

node_modules/ember-template-component-import/index.js:97:35)

I've attached the full stack trace.
stacktrace.txt

ember-cli: 3.7.1
node: 10.15.1
os: darwin x64

[jderr-mx]

I looked into this a little more and I was getting this error due to not having podModulePrefix defined in config/environment.js I was using namespaced components under app/components

I played around with adding an assertion to give a little more information:

    const podModulePrefix = this.project.config('development').podModulePrefix;

    assert.notStrictEqual(
      podModulePrefix,
      undefined,
      `${this.name}: 'podModulePrefix' has not been defined in config/environment.js`
    );

    registry.add('template', {
      name: 'ember-template-component-import',
      ext: 'hbs',
      toTree: (tree) => {
        let componentsRoot = path.join(this.project.root, podModulePrefix);
        tree = new TemplateImportProcessor(tree, { root: componentsRoot });
        return tree;
      }
    });

This way ember s would display
ember-template-component-import 'podModulePrefix' has not been defined in config/environment.js

I attempted putting this into a PR but I am not familiar with husky and commitlint and couldn't create a commit 😂

Thoughts?

[lougreenwood]

I'm also seeing this, however I'm attempting to use the addon in a non-pods application.

My reason fro this is that MU seems that it is going to template imports to work around the nested angle brackets problem (as well as other isssues) and this addon happens to provide a syntax and usage which is very close to the current proposal.

Is this addon inherently tied to use only with Pods?

[lougreenwood]

I spoke too soon - it seems the addon works fine for non-pods components too.

I simply added podModulePrefix: "pods", to my environment.js and it works.

Although it would be nice if that wasn't required to trick the addon into working...

[NullVoxPopuli]

I just ran into this with a fresh octane app.

I also had to add podModulePrefix: "pods" in order to trick this addon.

I've added this note to my environment.js:

    // TODO: remove when 
    // https://github.com/crashco/ember-template-component-import/issues/6
    // is resolved
    podModulePrefix: 'pods',

[davewasmer]

Originally, the sole purpose of this addon was to allow pods apps to use angle bracket syntax. I haven't tested it against MU apps at all.

If it works with MU apps, that's great, and I'd be happy to look at PRs that would remove the need for the podModulePrefix: 'pods' bit. But I probably won't be getting around to that anytime soon myself.

@lougreenwood I'm curious to understand why you're using this in a classic app - angle brackets should work fine there. Are you using it to invoke components nested inside the components/ folder?

[davewasmer]

Closing this for now since it seems like the newly merged assertion should handle anyone else hitting this scenario. Happy to reopen if it turns out something else is needed here.

[lougreenwood]

@davewasmer I'm using the addon to work around nested components - irrespective of Pods, angle brackets can't handle nested components in any form.

The addon allows me to use nested components with angle brackets and is pretty much in line with the proposed template imports RFC. An example of nesting to organise components by their context would be placing all input components together, e.g: components/inputs/radio-button.

Take a look here for what handlebars templates might look like in the future with MU:

https://github.com/emberjs/rfcs/blob/strict-mode/text/0000-handlebars-strict-mode.md#3-no-dynamic-resolution

This addon allows something very close to the proposed syntax right now and could later be find/replaced to the future syntax - allowing progressive adoption of strict handlebars - i.e I think this add on is going to prove to be more valuable to the community than you might have anticipated ;)