Import syntax should "just work" for ES6 modules available via npm

[runspired]

Many 3rd part libraries that aren't ember-addons provide es6 versions of their modules. At the moment, consuming these is hard without a shim-addon + custom broccoli-funnel+babel or using something like ember-rollup.

I believe this is something we should make "just work".

[runspired]

One thought I've had on this is that we could add a "resolvedTree" which is merged into the vendor tree at the end.

Essentially:

• Find unknown imports in app/addon tree
• Add a default resolver that checks for installed npm packages (possible erroring with suggested missing packages when not found?) (Allow for custom resolution strategies?)
• Add needed file(s) to the tree using rollup (allow configuration?)
• Pass the tree through babel transform (definitely allow configuration of this)
• merge with vendor

[stefanpenner]

I believe this is something we should make "just work".

The fun bit, is how does one support this in add-ons and nested addo-ns. E.g. the lack of a highlander node_module is the source of us never rolling ember-browserify or similar in by default.

There are some problems/solutions:

• introduce the concept of a highlander dependency (only 1 dep can exists)
• allow duping (e.g. 15 versions of mkdirp problem) or worse, pulling in 2 or more things that pollute the global incompatible ways. All while accidentally increases byte size
  • this would require name mangling so that different things wont collide (Fix all the things ef4/ember-browserify#100 spiked this, but the lack of highlander made this unappealing)
• ??

---

Doing this automagically has its risks (surprise inclusions, and a more complicated implementation). I believe we should strongly consider the npm: or similar approach as ember-browserify took. As it neatly addresses the issues.

[stefanpenner]

@runspired one of the things:

• Anonymous AMD Support ember-cli#5976 needs to be documented.

[quantuminformation]

I heard this will work for 2.14 or 2.15?

[boris-petrov]

We are using Ember-CLI 2.15 beta 1 because it works there (and is mentioned in the release notes).

[quantuminformation]

Great thx.

[bjornharrtell]

Sounds nice. @boris-petrov which mention are you refering to though? Is it ember-cli/ember-cli#7045?

[boris-petrov]

@bjornharrtell - this is the PR, yes. I was talking about this, where it says #7045 Make app.import() work with files inside node_modules @Turbo87.

[bjornharrtell]

Isn't this RFC broader scoped though? I.e to be able to import modules statically from npm dependencies in app code? I'm often finding myself wanting that and working it around by either importing the source into the project or symlinking the source into the app dir which both are hacky and error prone.

[sandstrom]

@runspired Can this be closed now that 2.15 is out, or does this issue cover something that wasn't added in 2.15?

[rwjblue]

No, not yet. This issue is roughly tracking being able to add import something from 'some-package-here'; into any file in your app, and having the build system bundle that dependency into the build (with some caveats of course). We are on the path for this, but not there yet...