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...

[caseywatts]

The app.import node_modules change in 2.15 helps a bunch! Here's a gist I made of how I used that for c3js/d3js: https://gist.github.com/caseywatts/347e18e4905c447859fa777ec97c34f8

It definitely seems like something that could be automated - the only difference between the two is the package name duplicated everywhere, e.g. c3. (I like that this issue is specifically about es6 module imports - I don't mean to suggest that css imports that I have in my gist are related to this issue)

[karellm]

I would be curious if there is any update about this issue. I'm trying to write an addon for ckeditor 5 and they have a multi package architecture that exposes only ES6 modules.

I tried ember-rollup but it looks unmaintained and quite boggy. It doesn't support scoped packages so I cannot tell it to import @ckeditor/ckeditor5-editor-balloon for instance. It requires the package.json to have a main source but some packages don't. And last but not least, the detection of ES6 module relies on jsnext:main in package.json that is far from broadly supported.

I would love to hear if anyone have a pointer how to achieve this. I don't mind doing the suggested "shim-addon + custom broccoli-funnel+babel" if that's what it takes, I'm just not very familiar with these. Thanks!

[jamescdavis]

https://github.com/ef4/ember-auto-import

[alansouzati]

I second @karellm. Please provide reference on how to achieve this. I'm facing a hard time trying to integrate a third-party es6 library in the ember ecosystem 😢

[karellm]

@alansouzati I haven't tried it personally but have you considered ember-auto-import linked above?

[rwjblue]

We are working on closing the ember-cli/rfcs repo in favor of using a single central RFC's repo for everything. This was laid out in https://emberjs.github.io/rfcs/0300-rfc-process-update.html.

Sorry for the troubles, but would you mind reviewing to see if this is still something we need, and if so migrating this over to emberjs/rfcs?