Comparison to ember-browserify

[lolmaus]

Hi!

Read about your addon in Ember Weekly.

Please update your readme with a comparison between ember-cli-node-modules-to-vendor and ember-browserify: what goals each of them pursues, what are their benefits and drawbacks?

ember-browserify, for example, is not suitable for addons: imported modules will be not found in the addon unless they are also imported into the host app's codebase.

[kellyselden]

Thanks for bringing it up. I'll try to get to it. Basically it gives you more control.

• It allows importing more than one file from a package.
• It allows conditionally import something, for instance don't import in fastboot environment.
• It allows importing non AMD files (globals)

[lolmaus]

Does it support Node modules (CommonJS)?

[kellyselden]

The importing itself is delegated to ember-cli app.import. For example, as of ember-cli 2.9, you can do

app.import('vendor/a-file-from-the-folder-above.js', {
  using: [{ transformation: 'amd', as: 'some-package' }]
});

to import AMD modules. All my addon does is include files in the vendor tree, it doesn't do importing.

[lolmaus]

That's an important clarification. Can you add that to readme and compare with ember-browserify?

[ef4]

Just wanted to chime is as original author of ember-browserify and the app.import transformation stuff:

I like this addon a lot. I think people should prefer this addon over ember-browserify when the library they're trying to add is distributed via npm and supports loading via AMD. That covers many of the common cases.

The time to reach for ember-browserify is when the library you're trying to add is distributed via as multiple CJS modules that need to be combined before they're usable in the browser.

Thanks.

[chadian]

@ef4 Is this still the case with ember-cli-cjs-transform, which the Ember guides point to. Internally it looks like it's using rollup along with a few plugins to resolve node and cjs modules. If there aren't any advantages to using ember-browserify maybe we can update the ember-browserify documentation with a recommendation for the guides.

[ef4]

I think cjs transform now does everything people usually need. Also ember-cli-node-modules-to-vendor itself is now a default behavior in ember-cli, so both it and ember-browserify should get documented as “probably not what you want”

[chadian]

Thanks @ef4 for coming up with https://github.com/ef4/ember-auto-import. It's finally the It Just Works™️ solution that we've been looking forward to in Ember. I suppose this addon ember-cli-node-modules-to-vendor would also be better replaced by ember-auto-import. @kellyselden what do you think?

[StephenAWalsh]

@ef4, we're currently migrating to auto-import since browserify is now deprecated. I'm curious how auto-import and browserify work under the hood. Clearly auto-import uses webpack. Interestingly I have a private addon that our host app imports. I had to use the webpack production flag in the addon's index.js in order to import mapbox.js, whereas browserify worked out-of-the-box. I also have to use app.import in the host app to get its icons.svg file in the asset pipeline, which was also the case with browserify. Can you offer any clarification?

[ef4]

I had to use the webpack production flag in the addon's index.js in order to import mapbox.js, whereas browserify worked out-of-the-box.

This is probably worth filing an issue for so we can figure out why that was needed.

I also have to use app.import in the host app to get its icons.svg file in the asset pipeline, which was also the case with browserify.

Both ember-browserify and ember-auto-import deal only with Javascript. I'm open to creating conventions for other assets (particularly "what happens if somebody says import "some.svg" or import "some.css"), but that is not a thing right now.