embroider-build / ember-auto-import

Zero config import from npm packages
Other
360 stars 109 forks source link

Build breaks after installing ember-link (which uses v1.11.2) #372

Open achambers opened 3 years ago

achambers commented 3 years ago

Hi @ef4 πŸ‘‹

I'm pretty sure I'm in the right place to ask about this bug, but if not, please let me know where I might be better off looking. Hoping I can find some joy here though.

Here's the deal.

I'm currently using Full Calendar in my app. I initially had a bit of trouble running it because it imports CSS in to JS, but I managed to get it working following a thread of instructions starting in https://github.com/ef4/ember-auto-import/issues/337

As a result I have ended up with the following ember-cli-build.js config:

    autoImport: {
      webpack: {
        plugins: [
          new MiniCssExtractPlugin({
            filename: 'vendor.css'
          })
        ],
        module: {
          rules: [
            {
              test: /\.css$/,
              use: [MiniCssExtractPlugin.loader, 'css-loader']
            }
          ]
        }
      }
    },

My app is currently using ember-auto-import@v1.10.1 things were working fine.

However, after installing https://github.com/buschtoens/ember-link, and making no other changes, the build barfs with:

Built at: 03/25/2021 16:11:02
                                      Asset      Size         Chunks                                Chunk Names
            chunk.0.df852c22e798aa6c6d83.js  24.5 KiB              0  [emitted] [immutable]
            chunk.1.6f589e0821d21fa42e3a.js   103 KiB              1  [emitted] [immutable]
            chunk.2.f9134757c7ec77afb5a7.js  86.1 KiB              2  [emitted] [immutable]
            chunk.3.bce1c8df9c64abed8be4.js  35.9 KiB              3  [emitted] [immutable]
          chunk.app.e617aed343d48045303c.js  20.2 KiB            app  [emitted] [immutable]         app
        chunk.tests.886b9d7ec25151a7af99.js  10.9 KiB          tests  [emitted] [immutable]         tests
  chunk.vendors~app.3f74f28edbd553570d26.js  12.8 MiB    vendors~app  [emitted] [immutable]  [big]  vendors~app
chunk.vendors~tests.96986d5620b8b06a309f.js  44.4 KiB  vendors~tests  [emitted] [immutable]         vendors~tests
Entrypoint app [big] = chunk.vendors~app.3f74f28edbd553570d26.js chunk.app.e617aed343d48045303c.js
Entrypoint tests = chunk.vendors~tests.96986d5620b8b06a309f.js chunk.tests.886b9d7ec25151a7af99.js
[0] multi /private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/l.js /private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/app.js 40 bytes {app} [built]
[3] multi /private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/l.js /private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/tests.js 40 bytes {tests} [built]
[../../../../../private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/app.js] /private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/app.js 6.37 KiB {app} [built]
[../../../../../private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/l.js] /private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/l.js 50 bytes {app} {tests} [built]
[../../../../../private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/tests.js] /private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/tests.js 1.15 KiB {tests} [built]
[./node_modules/@apollo/client/core/index.js] 1.08 KiB {vendors~app} [built]
[./node_modules/@apollo/client/link/context/index.js] 842 bytes {vendors~app} [built]
[./node_modules/@ember-intl/intl-messageformat/index.js] 553 bytes {vendors~app} [built]
[./node_modules/@ember-intl/intl-relativeformat/index.js] 557 bytes {vendors~app} [built]
[./node_modules/@fullcalendar/core/main.js] 4.42 KiB {vendors~app} [built]
[./node_modules/@fullcalendar/interaction/main.js] 84.1 KiB {vendors~app} [built]
[./node_modules/@fullcalendar/resource-timegrid/main.js] 9.19 KiB {vendors~app} [built]
[./node_modules/@fullcalendar/scrollgrid/main.js] 41.7 KiB {vendors~app} [built]
[./node_modules/@sentry/browser/esm/index.js] 708 bytes {vendors~app} [built]
[./node_modules/@sentry/integrations/esm/ember.js] 1.94 KiB {vendors~app} [built]
    + 2123 hidden modules

ERROR in ./node_modules/@fullcalendar/timegrid/main.css
Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/mini-css-extract-plugin/dist/loader.js):
Error: Didn't get a result from child compiler
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/mini-css-extract-plugin/dist/loader.js:209:23
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compiler.js:343:11
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compiler.js:681:15
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:31:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compiler.js:678:31
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compilation.js:1423:35
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compilation.js:1414:32
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compilation.js:1409:36
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compilation.js:1405:32
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at Compilation.seal (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compilation.js:1342:27)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compiler.js:675:18
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/NormalModule.js:316:20
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/loader-runner/lib/LoaderRunner.js:367:11
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/loader-runner/lib/LoaderRunner.js:182:20
    at context.callback (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/mini-css-extract-plugin/dist/loader.js:209:14
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compiler.js:343:11
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compiler.js:681:15
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:31:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compiler.js:678:31
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compilation.js:1423:35
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compilation.js:1414:32
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compilation.js:1409:36
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:4:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/wadewilson/Code/phorest/phorest-desktop-ember/node_modules/webpack/lib/Compilation.js:1405:32
 @ ./node_modules/@fullcalendar/timegrid/main.js 6:0-20
 @ ./node_modules/@fullcalendar/resource-timegrid/main.js
 @ /private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/app.js
 @ multi /private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/l.js /private/var/folders/6s/bp7y89h93x96fchvhvsgtqhm0000gn/T/broccoli-87486knvNNF3qZEj5/cache-1124-bundler/staging/app.js

I noticed that ember-link pulls in ember-auto-import@v1.11.2.

Can you point me in the direction of what might be causing this build error after having simply installed the ember-link addon?

If there is any extra info I can provide, please let me know.

Thanks in advance πŸ™

buschtoens commented 3 years ago

Heyo πŸ‘‹πŸΌ

Are you using yarn?

Can you give https://github.com/salsify/ember-cli-dependency-lint and https://github.com/atlassian/yarn-deduplicate a try?

I suspect that yarn did not optimize / deduplicate the yarn.lock when ember-link was installed. So now you have multiple versions of ember-auto-import, and as it seems, the wrong version got loaded first and thus is the "main" version.

If this doesn't fix it, e.g. by upgrading all to the same (e.g. latest 1.11.2), try using a yarn resolution to enforce a specific version for all dependencies.

achambers commented 3 years ago

Hi @buschtoens πŸ‘‹

Thanks for stepping in. Yep, I figured it’s to do with the version of ember-auto-import being used. Was finding it hard to determine exactly which version was being used when it worked and when it failed. I tried using yarn resolutions but it didn’t seem to make any difference πŸ€·β€β™€οΈ

I do use yarn so will give your suggestions a try and report back how I get on.

Thanks again for your prompt reply :)

achambers commented 3 years ago

@buschtoens I'm trying to reconcile the fact that ember-cli-dependency-lint mentions that it ignores ember-auto-import by default (https://github.com/salsify/ember-cli-dependency-lint#build-time-addons) citing:

Different addons your app uses should be able to compile using whatever tooling they like without conflicting with one another.

I'm not super familiar with how ember-auto-import works, but do you think that if I try and use the dependency-lint it would make sense for me to ensure it does lint ember-auto-import?

achambers commented 3 years ago

Ok, I've spent a bunch of time installing, and then reinstalling dependencies and it seems that the version of ember-auto-import that seems to work, when pinned, and after ember-link has been installed is 1.5.2. Anything after that seems to give the error.

I sure would love some suggestions on where to go next with this πŸ€”

achambers commented 3 years ago

Ok, another update. I went back to master, from before I installed ember-link and can replicate this. I noticed that the versions of ember-auto-import that were installed ranged from 1.5.2 (from one of our dependencies) to 1.10.1 (from our dev dependency which specified ^1.8.0.

I pinned (via the resolutions prop of the package.json file) every version of ember-auto-import starting at 1.5.2 and can confirm that the last working version was 1.10.0 and then pinning 1.10.1 breaks when starting the ember server.

So, what is it about the changes between these two versions (https://github.com/ef4/ember-auto-import/compare/v1.10.0...v1.10.1) that's causing the error I posted in the issue description? I'm feeling out of my depth at this point so any advice would be super appreciated.

Pinned versions of ember-auto-import tested

1.5.2 βœ… 1.5.3 βœ… 1.6.0 βœ… 1.7.0 βœ… 1.8.0 βœ… 1.9.0 βœ… 1.10.0 βœ… 1.10.1 ❌ 1.11.0 ❌ 1.11.1 ❌ 1.11.2 ❌ 1.11.3 ❌

(Update: Added 1.11.3 as another non-working version)

achambers commented 3 years ago

Apologies for the stream of consciousness here. Just trying to get all the facts down in the hope someone can help me.

The error I am seeing is exactly this https://github.com/emberjs/ember-test-helpers/issues/961

I know this is in a difference repo but it was linked to from https://github.com/ef4/ember-auto-import/issues/337

I have upgraded ember-qunit to the latest and the installed qunit and @ember/test-helpers (due I think to the fact that ember-qunit no longer brings them in). I've confirmed that the version of @ember/test-helpers is >=2.2.1 which apparently contained the fix.

Still no joy though.

That issue in the ember-test-helpers still doesn't explain to me why 1.10.0 works and 1.10.1 doesn't so I'm completely flummoxed πŸ€”

buschtoens commented 3 years ago

Thanks for all the analysis you've done already. It's really helpful. I don't know, whether I can find the root cause, but this surely is enough for others to go off on.

@buschtoens I'm trying to reconcile the fact that ember-cli-dependency-lint mentions that it ignores ember-auto-import by default (salsify/ember-cli-dependency-lint#build-time-addons) citing:

Different addons your app uses should be able to compile using whatever tooling they like without conflicting with one another.

I'm not super familiar with how ember-auto-import works, but do you think that if I try and use the dependency-lint it would make sense for me to ensure it does lint ember-auto-import?

Oh, I didn't recall, that ember-auto-import is ignored by default. It makes total sense, because ember-cli-dependency-lint is meant to guard against conflicting versions in the output bundle, and not with the build tools creating the bundle, as these tools usually all operate in isolation in the scope the addon they are a dependency of.

This is not completely true for ember-auto-import, as all instances talk with one another. IIRC the first instance of ember-auto-import that loads is the "winner" and becomes the main instance that all other instances delegate to.

This explains, why installing a new addon that has a dependency on ember-auto-import can cause an out dated or unexpected version to become the main one.

So, what is it about the changes between these two versions (v1.10.0...v1.10.1) that's causing the error I posted in the issue description? I'm feeling out of my depth at this point so any advice would be super appreciated.

Hm, looking at the commits there appear to be no relevant changes at all. Maybe there is an off-chance, that the resolution is not working 100 % correct, or that there are transitive dependencies, which don't resolve correctly?

Have you tried verifying this bit of https://github.com/ef4/ember-auto-import/issues/337#issuecomment-756541525?

webpack/webpack#10843 seemed to provide a bit of a clue.

And when I run ember with the debug flags for auto-import, I see this

ember-auto-import:bundler extraWebpackConfig {"module":{"rules":[{"test":{},"use":["style-loader","css-loader"]},{"test":{},"use":["style-loader","css-loader"]}]}} +0ms

So it looks like something is causing the rule to appear twice.

If I look through the process using node debugger, I can see that my ember application ends up in the Set of packages this.options.packages twice.

I think that this is a likely cause. If so, we can try to dig in deeper there and find out, why that's happening.

ef4 commented 3 years ago

IIRC the first instance of ember-auto-import that loads is the "winner" and becomes the main instance that all other instances delegate to.

It's not precisely the first copy, it's the first copy of the newest version that's present. But yes, that means it's OK to have multiple versions floating around.

I would debug this further by getting into a debugger at node_modules/mini-css-extract-plugin/dist/loader.js:209:23 and working back from there to see what "Didn't get a result from child compiler" really means.

Taking a guess, I suspect this is likely to be a package manager problem (some package is seeing a version of another package that it shouldn't be.)

achambers commented 3 years ago

Thanks @buschtoens and @ef4 for your suggestions. I'll dig deeper taking on your thoughts and see where I end up. Will report back here to, hopefully, tie up the loose ends for anyone else that finds themselves here.

achambers commented 3 years ago

Ok, I'm getting closer, I think. I have verified that I am also seeing this:

webpack/webpack#10843 seemed to provide a bit of a clue.

And when I run ember with the debug flags for auto-import, I see this>

ember-auto-import:bundler extraWebpackConfig {"module":{"rules":[{"test":{},"use":["style-loader","css-loader"]},{"test":{},"use":["style-loader","css-loader"]}]}} +0ms

So it looks like something is causing the rule to appear twice.

If I look through the process using node debugger, I can see that my ember application ends up in the Set of packages this.options.packages twice.

When using ember-auto-import v1.10.0, I get this:

{
    "plugins": [
        {
            "_sortedModulesCache": {},
            "options": {
                "filename": "vendor.css",
                "ignoreOrder": false,
                "chunkFilename": "[id].vendor.css"
            },
            "runtimeOptions": {
                "linkType": "text/css"
            }
        }
    ],
    "module": {
        "rules": [
            {
                "test": {},
                "use": [
                    "/Users/wadewilson/Code/phorest/implement-web-only-designs/node_modules/mini-css-extract-plugin/dist/loader.js",
                    "css-loader"
                ]
            },
            {
                "test": {},
                "include": {},
                "type": "javascript/auto"
            }
        ]
    }
}

When using ember-auto-import v1.10.1, I get this: (you can see duplication that isn't present in the above)

{
    "plugins": [
        {
            "_sortedModulesCache": {},
            "options": {
                "filename": "vendor.css",
                "ignoreOrder": false,
                "chunkFilename": "[id].vendor.css"
            },
            "runtimeOptions": {
                "linkType": "text/css"
            }
        },
        {
            "_sortedModulesCache": {},
            "options": {
                "filename": "vendor.css",
                "ignoreOrder": false,
                "chunkFilename": "[id].vendor.css"
            },
            "runtimeOptions": {
                "linkType": "text/css"
            }
        }
    ],
    "module": {
        "rules": [
            {
                "test": {},
                "use": [
                    "/Users/wadewilson/Code/phorest/implement-web-only-designs/node_modules/mini-css-extract-plugin/dist/loader.js",
                    "css-loader"
                ]
            },
            {
                "test": {},
                "include": {},
                "type": "javascript/auto"
            },
            {
                "test": {},
                "use": [
                    "/Users/wadewilson/Code/phorest/implement-web-only-designs/node_modules/mini-css-extract-plugin/dist/loader.js",
                    "css-loader"
                ]
            }
        ]
    }
}

And here's a diff of the two:

image

So, this is leading very much to this being the same issue as reported in https://github.com/emberjs/ember-test-helpers/issues/961. The funny thing though is that I have tried to update the version of @ember/test-helpers a few days ago but it didn't seem to work.

I'll try that path again to make sure I didn't do something incorrect.

(Also, I still can't make sense in my head why updating from ember-auto-import 1.10.0 to 1.10.1 would cause this if it isn't actually ember-auto-import that's at fault. I can't connect those dots in my mind yet).

achambers commented 3 years ago

Ok, so, upgrading the version of @ember/test-helpers, as is the suggested solution in https://github.com/emberjs/ember-test-helpers/issues/961 does not seem to work for me. I can't place why that might be.

The one difference is that I am using Ember 3.23.1, but all the reports in the issue describe it from happening when upgrading to 3.24.x. I suspect that this is the case because 3.24.x introduces ember-auto-import 1.10.1. Whereas I've specifically pinned that version my 3.23.1 app.

And, because I'm on 3.23.1 I've had to do the following to upgrade to the latest version @ember/test-helpers which supposedly has the fix.

  1. yarn upgrade ember-qunit --latest
  2. yarn add qunit @ember/test-helper -D

I guess now it might be time to put a comment in https://github.com/emberjs/ember-test-helpers/issues/961 to ask for help. Still, I still would like to understand why upgrading from ember-auto-import 1.10.0 to 1.10.1 is the trigger for this error.

ef4 commented 3 years ago

Ah, so if this was being caused by duplicated webpack config, then it may be fixed by https://github.com/ef4/ember-auto-import/pull/377

achambers commented 3 years ago

@ef4 Oh, that looks promising. I see it's not been released yet. I'll keep an eye out for v1.11.3 to verify if it fixes the issue.

achambers commented 3 years ago

@ef4 Are you able to release master so I can verify if #377 fixes this?