Import conflict when using in a project along-side ember-auto-import

[urbany]

Hi, when using this addon in a project which also uses "ember-auto-import" the moment import in the addon seems to trigger ember-auto-import instead of ember-cli-moment-shim

ember-auto-import:splitter bundleForPath("ember-power-calendar-utils/index.js")=app +0ms
ember-auto-import:splitter output {
"app": {
  "static": [
    {
      "specifier": "moment",
      "entrypoint": "/myproj/node_modules/moment/moment.js",
      "importedBy": [
        {
          "package": "ember-power-calendar-moment",
          "path": "ember-power-calendar-utils/index.js",
          "isDynamic": false
        }
      ]
    },

this way I end up with moment imported twice into my vendor.js
I tried using the exclusefrom ember-auto-import without success. Not sure if the problem is ehre or with https://github.com/ef4/ember-auto-import

[cibernox]

@urbany what version of the addon are you using?
When I decided to move to ember-auto-import + moment I kind of felt this problem coming, and I don't think I have a good solution.

Using ember-auto-import and adding a shim are mutually exclusive options, an app shouldn't use both. I asked the core team which option was more "recommended" going forward and people seamed to lean towards e-a-i + moment instead of the shim, and that's why I made the change.

The only answer I have is that you stop using the shim yourself and use auto import + moment too. I believe that in that case it won't be duplicated.

Keep me posted of what you find, I want to know for sure that it works.

[urbany]

Thanks for the quick reply! I'm using 0.8.0.

The only idea I have would be to have a way to control the excludes from the addons, since the excludes I add to my ember-cli-build don't take the addon imports into account.

I would stop using the shim but I need to know how to prevent e-i-a from importing all the locales first I created an issue in e-i-a embroider-build/ember-auto-import#114

You might want to add something to the readme saying it is not compatible with the shim.

[cibernox]

So ember-auto-import imports moment with all the locales? I did not know that. That's surely something to fix.

[urbany]

Yes it does, and I think that's the normal way because I see many posts about that in other platforms that use webpack, this seems to be a way of getting around that but not sure how to implement it with e-a-i: moment/moment#1435 (comment)

[cibernox]

FWIW, I'm working on finalizing https://github.com/cibernox/ember-power-calendar-luxon If you are not familiar with luxon, is also a project from the same people as moment.js but with a modern API and that doesn't needs any locales as it uses the Intl API in modern browsers. Depending on how much you use moment the migration might take some time, but I switched and it's very good. El jue., 23 ago. 2018 a las 18:51, João Teixeira (<notifications@github.com>) escribió:

…

Yes it does, and I think that's the normal way because I see many posts about that in other platforms that use webpack, this seems to be a way of getting around that but not sure how to implement it with e-a-i: moment/moment#1435 (comment) <moment/moment#1435 (comment)> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#164 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAQMe0jZn39fNvskomTzQ7DFgAgofI_Tks5uTt11gaJpZM4WJ19Z> .

[cibernox]

@urbany I've released 0.8.1 in which I rollback to using the shim. Can you verify that the bundle size stays low and moment is not duplicated?

I also believe now only the desired locales will be loaded.

[urbany]

@cibernox we found a solution with e-a-i, check my comment there embroider-build/ember-auto-import#114 (comment)

I'm testing it now to see if everything is ok, might be a good idea to stay with e-a-i here, or update the shim to use e-a-i internally.

[cibernox]

It would be great if ember-cli-moment-shim starts using e-a-i internally. Another bug about timezones was reported in #162 , which I believe it's because of the duplicated moment.

Wether it's the best approach or not, ember-cli-moment-shim is by far more used today than e-a-i+moment, so I think that keep using it, even if it just for some transition period or weeks or months will ease the upgrade.

[urbany]

After the comments here jasonmit/ember-cli-moment-shim#168 not sure what the solution will be so might be a good idea to warn people that if they use ember-power-calendar-moment and ember-auto-import at the same time they will end up wioth moment imported twice to their vendor.js. The best option for now is to tell ember-auto-import to ignore moment, and only use moment from the ember-cli-moment-shim.
To ignore moment in ember-auto-import:

// in ember-cli-build.js
const IgnorePlugin = require('webpack').IgnorePlugin;
let app = new EmberApp(defaults, {
  autoImport: {
    exclude: ['moment'],
  },
});

You might close this if you want.

[cibernox]

I want to highlight that since 0.8.1, this is not a problem anymore, as ember-power-calendar-moment depends on ember-cli-moment-shim and doesn't use ember-auto-import.

[urbany]

@cibernox I think the problem still exists if someone is already using e-a-i in their app to import moment, and then they install e-p-c-m which brings the shim into play.

[cibernox]

That is true, but since e-a-i is fairly new, most people will be using the shim. And for what I see on that thread, there are caveats with including the locales using e-a-i so the shims seems a better option right now.